Troubleshooting

Computers are not magic. Nothing in technology is. Computers are tools that follow the operator’s instructions. Commands can be complex, and underlying code can possibly be send incorrect instructions, but in the end, there is no room for interpretation. Computers cannot ‘get mad’ at you, or have a bad day, or do something that they’re not told to do. Not yet, anyway.

I deal with technical problems every day. Generally, I try to solve them, with methodical and unambiguous techniques that produce quantifiable results. That’s a complicated way of saying I work on a problem until it’s solved and I know why it happened. This is a cornerstone of my entire professional life, and the process is simple. No matter how complex your problem, troubleshooting follows the same steps:

1. You have a problem. Define it.
2. Identify the variables (what can change, especially what you can change).
3. Change one variable
4. Test. Do you still have the problem? If not, quit, you have solved it.
5. Change your previous variable back.
6. Change another variable.
7. Test.
8. Repeat until a solution is found. Eventually, you will be rewarded.

Sometimes you get a complicated problem, with interaction between multiple variables. But that’s when your process has to be absolutely methodical and boring. Even if the system is burning down around you — especially if the system is burning down around you — you must stay calm; troubleshooting takes as much time as it takes.

I bring this up because, over the years, I have encountered a staggering number of technical people — engineers, computer scientists, systems and network administrators — who do not manage to be methodical, for one reason or another. Many people in the IT field don’t have a good troubleshooting process, and waste a lot of time and effort as a result — both their own, and that of those they work with (like me). Even if they solve a problem, they won’t know the cause, won’t be able to recreate the problem, cannot come up with a permanent fix, and cannot apply this experience to future problems.

Sometimes these folks are highly pressured and attempt everything they can think of at once. Sometimes they ‘don’t care what the problem is, as long as it’s fixed.’ Many times they simply do not have a background in or experience of problem solving, and also don’t understand what benefits a step-by-step process brings. But a cool head, methodical work habit, and good documentation, combined with sensible precautions (you did back up, right?) will always yield the desired results. Rushing and not knowing why things are working will only lead to problems down the road.

I would like to thank the science teachers I had in California public school, who taught me how to design an experiment at an early age. I’m not sure if it was third grade or seventh, but valid experimental procedure has become my ingrained response to solving technical problems. Without it, I wouldn’t have had a good job in university, wouldn’t have managed a technology career, and would not have the life I lead today. My hat is off to you, my former teachers. Here’s hoping there are still some people out teaching the basics.