1

Sometimes, when asking technical questions, the questions that we ask provide more information than we realize. In a previous article, Asking Better Questions , one of the key things that I mentioned is the need to “pull back one level.” By the time that we have a technical question there is a very good chance that we have already gone too far, past the point where we have sufficient knowledge to support ourselves, and may have already made a bad decision.

Sometimes this is even more dramatic. That the question we are asking means that we should not be doing the thing we are attempting at all. A great example of this is when someone asks a really basic question about a very dangerous, and complicated topic (dangerous being the key warning indicator.)

Imagine you are about to jump out of an airplane and you say to the person next to you “so do I count to ten and pull a cord or something like that?” or worse “should I have some special backpack or something.” DANGER WILL ROBINSON. You’ve gone too far. You should never, ever have gotten into an airplane with the intention to jump out of it without understanding parachutes, jump procedures, harness techniques, landing techniques, the terrain you are over and all kinds of specifics about the parachute that you are using that particular day. That you are asking the question is answer a bigger question - Should you be jumping out of an airplane? No.

In IT we see this same scenario. A question that, in its asking, exposes that the asker has gone too deep, is already on the airplane and didn’t learn about skydiving first. The situation is dangerous and that they are not aware is the real problem.

Some places where we see this most often are with storage, an area where it seems most common to make decisions before learning about the technology and the questions asked are ones that would have needed to have been answered long before getting to the current point. But it can happen in any technical arena, storage just gets a high profile here because the dangers are so much more dramatic as they often lead to both data loss and loss of availability at the same time and often across many systems.

Don’t take offense when people have this reaction. Stop and ask yourself if it is true. Do you really understand the technology that you are involved with, are you confident that you are familiar with its use and caveats and that you really are just missing some really basic understanding that is not crucial to have had before getting as far as you have? Or are you perhaps operating somewhat blindly and may not understand how you got to where you are and are working in the dark - taking on risks and not being able to understand or explain them clearly.

There is no shame in admitting what you don’t know. But there is in putting a business at risk because you were hoping that no one would notice what you didn’t know. None of us understands every aspect of what we do, we all have tons of questions and need help from lots of people. Get that help as early as possible, don’t wait until you are about to jump and then decide that maybe you should know where the ripcord is.

Geronimo…

89 Spice ups
2

Well said Scott. There is definitely a difference between

“I’m experiencing this error I’ve seen before and I’ve troubleshooted it by doing X, Y and Z but I still need help” and “I just got a new job and need to setup a domain. How do I do that?”

I thought your illustration was most appropriate. If you don’t have some fundamental knowledge about something, then jumping in with both feet is a good way to learn but not if you’re in a production environment where you compromise a company, people’s livelihoods and your own job as well as career.

Playing at home in your test environment is fine. But don’t be breaking stuff where and when it counts.

6 Spice ups
3

Woohoo! I was the first to spice it up and the first comment!! :smiley:

5 Spice ups
4

hehehhehe :wink:

images.jpg

12 Spice ups
5

Perfect example of why I have not moved from SBS 2008 and Exchange 2007 to Server 2012 and Exchange 2013. Not enough knowledge on it and all the caveats and issues I could run into. Well put SAM.

2 Spice ups
6

Questions should be asked early and often. One also has to take it upon themselves to do a little research and read first too.

2 Spice ups
7

“If you can’t explain it to a six year old, you don’t understand it yourself.” -Albert Einstein

11 Spice ups
8

Don’t be this guy!

skydive.png

2 Spice ups
9

I was talking to my better 7/8ths about similar things yesterday. In a one man shop you have to be good at Exchange, hardware, AD, AV, SQL, SharePoint, all the LOB apps; it’s a huge list to try to specialize down to one. It was better for me to make sure the things I didn’t know were handled by those who do, so I can focus on the things specific to the office here. I’d rather ask the question at the beginning of the project and find out if I have the time and the skills to do the company justice.

“Some places where we see this most often are with storage, an area where it seems most common to make decisions before learning about the technology and the questions asked are ones that would have needed to have been answered long before getting to the current point.” Could be worse. I’m doing cursory looks in the job market because the attitude here has been revealed that the amount of time learning the nuances of the tech that is being used does not directly affect the billable income for the office, and the time down from an emergency from not knowing/implementing the wrong thing just isn’t worth the cost of training.

1 Spice up
10

Yeah, I love posts like the ones SAM is referencing. It’s like watching a train wreck in slow motion…

7 Spice ups
11

The same is true for fulfilling end user requests. Often a user’s request for something isn’t really what they want or need at all, and by going up one level from what they are asking for we discover what the expected outcome really is and from there can build a solution that delivers. For example, “I need Dropbox” moves up one level to “I need to send artwork to the vendor so they can complete their portion of the project”. The answer may end up being Dropbox for a variety of reasons, but until one steps back to see the wide angle view an appropriate solution won’t be identified as such.

3 Spice ups
12

Plato — ‘I am the wisest man alive, for I know one thing, and that is that I know nothing.’

8 Spice ups
13

i-know-nothing1.jpg
i-know-nothing1.jpg450×544 60.3 KB
3 Spice ups
14

… so, I bought this server with 3 disks and my budget is gone. Should I use RAID 5?

3 Spice ups
15

That depends :wink:

2 Spice ups
16

Just as bad is when you get someone who is in over their head and someone jumps in with a post that starts something like “EASY FIX” that has nothing to do with the situation, and will make it exponentially worse.

Trying to justify an “I just blew up our domain/exchange/sql because some guy on the internet forum I joined today said it was ok” is probably a resume generating event (RGE if you will).

4 Spice ups
17

I prefer CLM, Career Limiting Maneuver.

2 Spice ups
18

(FUD) F’ Up Decisively

1 Spice up
19

Ture stuff

20

Great post and very true.

I see this all too often with programming topics as well. I find myself telling people “you need to think about the design of this project” more often then I would care to, when all they wanted was a snippet of code.