The ability to program in five languages, including one machine-level? Not it.
Project management skills, up to and including a PMP certification? Not that either.
Excellent oral and written communication skills, as noted on every job description ever? That doesn’t hurt, but can be learned.
All of the best IT professionals I have worked with have excellent problem solving skills.
That’s it.
We face problems in IT on a regular basis. From the help desk technicians who are asked, “Why am I locked out of my computer?” to the SAN administrators who have to balance the needs of different servers and workloads to the DBA who is asked, “Why is the server so slow?” we are all given problems to solve.
How we go about solving those problems is what sets the great professionals apart from the good or the average.
Problem Solving Methodology
In high school, I was introduced to the scientific method. The process is:
- Formulate a question.
- Make a hypothesis.
- Make a prediction.
- Test the hypothesis. Measurements are emphasized.
- Analyze the results.
Can this be applied to your problems? Yes, it can.
Formulate a question – usually, the question is asked of you. “Why is the server slow?” “Why can’t I connect to the database?” “Why is this report execution timing out?”
Make a hypothesis – perhaps a patch was installed on the server or SQL Server the night before. Maybe a network cable could have been unplugged. Maybe a developer changed a line of code in the stored procedure. Make a list of what could affect the system in question, so you have items to test.
Make a prediction – take a guess at what your results will be. If this is an error or problem you’ve encountered before, you’ll probably have a good idea of what to expect. If it’s a new problem, use your past experiences and deductive skills to determine what changes you make will do to the system.
Test the hypothesis – make a plan, make a change, and check if the problem is solved. Don’t make three changes and wonder which one fixed it – fix one at a time. Know what success looks like. If a query is slow, know what performance was before the problem occurred, what performance is when the problem is happening, and what acceptable performance looks like. Metrics are important here. You must be able to measure if things improved, stayed the same, or got worse.
Analyze the results – check those metrics. Did you get the results you expected? If so, is the problem resolved? If not, what is the next item on your list to check? Continue to iterate through your list until the problem is solved.
Anyone Can Do This
It doesn’t require a PhD in computer science. It doesn’t require a master’s degree in chemistry. What it does take is a consistent approach to problems every time. It takes curiosity and an ability to see patterns.
With practice, this becomes much easier. Practice your problem-solving skills often. They will make you a great IT professional, and set you apart from the rest of the crowd.
18 Comments. Leave new
**Don’t make three changes and wonder which one fixed it – fix one at a time**
This is perhaps the most important of all as I see it.
Far too often I see people try and solve problems and then due to – for example pressure from management, the client, time constraint or similar – a number of factors are tweaked/changed/corrected at once and suddenly – nobody has any overview of what did what and why and even what has been tried if it all fails.
The main way to really solve a problem is to eliminate factors (either because of experience with a similar problem) and if you loose overview or insight due to many factors being changed; well – you risk ending up back at square one much too often. (Or you get lucky and solve it and then cannot explain why to a client wanting an explanation)
Under Test… I would include: write down what you changed. This is important if what you tried worked and you need to document (or apply to multiple systems) or it didn’t and you need to roll back. Applying to scientific method, this is the written procedure you follow in your experiment.
The first step is often “Light hair on fire and run around”, which I see has been left off. I’m not sure troubleshooting will work without that. But seriously, I’ve found that spending extra time on formulating the question saves time downstream. I try to be as clear as possible about what the problem is rather than grabbing the error message and starting with that as the golden egg. I can’t say I practice this perfectly but when I do take the time to look (really look) at the problem it speeds my arrival at the solution.
From the title I was pretty skeptical, but it’s true. The ability to do problem solving, with a basic understanding of the scientific method, is really one of the most used skills I have.
I’ve noticed that when people struggle over and over that there is often a lack of understanding of the process and instead they jump to conclusions far quicker than I am able to.
Nice post Jes!
I just want to praise last paragraph more and more!
Curiosity is a must for every IT professional, regardless if it’s a Java developer or DBA.
Hi Brent, terrific post! 🙂 so true ! but I would add some “nuances”…
1)both problem solving skills *and* problem finding skills – don’t know what’s worst, when we got the wrong solution or the wrong problem in the first place, more often than not its the later…
2)I usually try (& advise) not to rush on the hypothesis step, try to gather info not thinking in any particular cause/solution, just gather a bunch of it, data, users feedback, let it “linger”…, we can’t go and try every possible hypothesis… just recently watched a team trying one cause after another when they could have fixed the issue in seconds/minutes if they just digged a little deeper to find the (internal/hidden to the web user) exception and stack trace. hypothesis should consider all the information we can collect.
http://seeitasitis.wordpress.com/2012/08/16/troubleshootingbeware-the-inattentional-blindness/
3)learn to read the f$#=@ stacktrace! 🙂
4) learn to code/build as to balance both solution robustness/error tolerance and error/anomaly visibility, human physical pain is a good analogy for this, it allow us to keep functioning but raises visibiltiy on any issue
My hypothesis is that you didn’t read the byline of the post… no stack trace needed. 🙂
on the spot 🙂 Kendra!
Jes, sorry! I truly apologize, congrats on your terrific post!
Maybe you could do a post series on the topic 😉 love it
Kind regards,
Rui
Three cheers for the scientific method.
I shared the same sentiment not too long ago.
http://michaeljswart.com/2012/10/you-can-do-science-anywhere/
Well done Jess!
Bisection is also useful. You cannot connect to SQL Server? Can you telnet to port 1433? If not your app is not at fault. If yes your app is misconfigured.
Hi Jes,
You’re absolutely right about this one skill. I would complement your post with the right character to succeed in IT: “The right attitude”.
There are so many people working in our domain with the wrong attitude. I wouldn’t mind hiring someone with zero experience but having the right attitude.
I totally agree. Attitude comes before competency.
Excellent points and agree completely. We often like to complicate things but at its core, methodical problem solving is what people who work with systems have to excel at!
The title of the post made me think, oh no, did these guys sign with a new web ad company? As in, “I gained 10,000 IOPS using this ONE WEIRD TRICK!” 🙂
I agree with all that’s been said for most problem occurrences. One variation I would suggest is for a problem that only occurs rarely may necessitate deviation from the ‘only change one thing at a time’ methodology because we just need to take a big swing at it and see if we can eliminate the problem. We then may circle back to isolate the true fix – maybe we won’t care. If this deviation is used – BE SURE TO DOCUMENT as the chances to inject a new problem are increased.
Oh, and that’s also what’s *keeping* me in IT
Great Article Jes. Under formulate a question I would add symptom recognition. Too often folks jump on the first symptom, ie a user says they have a slow report. I think it’s important to take a step back and see if other users are having the same issue. Also are there other issues on the network. Other SQL Server issues. The more info you gather the easier it is to narrow down the problem.
Sometimes it is hard to get time to do this, but it can save time in the long run.