I was recently reminded of tinkering’s more stressful cousin–troubleshooting–during an unexpected and extremely inconvenient wifi outage at my home. While I generally consider tinkering to be a relaxing and enjoyable pursuit, troubleshooting usually is quite the opposite. Troubleshooting is a higher-pressure, higher-stakes form of tinkering, inspired not by joy, but by necessity. With the right approach, however, troubleshooting does not have to be a painful experience.
In a CISCO networking course I took in my freshman year of high school, I learned the troubleshooting process that I still follow, even if subconsciously, to this day. CISCO’s 8 Step Process goes like this:
- Define the problem
In less jargon-y terms, this means “figure out what is going on and think about why that might be happening.” For all the following steps, it is important to be focused on what the actual problem is.
2. Gather information about the problem.
It is always important to take note of the current state of whatever you’re troubleshooting at the time you start to troubleshoot it. This step refines your definition of the problem and forces you to take note of what the symptoms of that problem are. The type of information you need to gather will vary wildly from problem to problem,
3. Narrow down the possible causes based on your information.
With a better understanding of the problem itself, you will have a better view of what might be causing the problem. More importantly, you will know what is not causing your problem, and you can save time by removing that from consideration.
4. Plan out the troubleshooting steps you want to take. Only take one step at a time.
Having a plan for how to go about trying to fix something is important. It will keep you on task and help you keep track of what has, and has not, made a difference as you work on troubleshooting.
5. Carry out the plans from Step 4.
Though CISCO recommends that you tackle the probable causes in order of most likely to least likely, I personally make a more subjective choice based both on the likelihood of solving the problem and the ease of attempting the fix. If the most likely cause is significantly more difficult or time consuming (or even destructive!), I will try an easier fix first. An easier fix will be easier to attempt and also easier to reverse with a smaller likelihood of making the problem worse.
6. Always take note of what happened when you made a change.
Regardless of whether the experimental fix does or does not make a difference, it is important to have an understanding of where the problem stands after making a change vs. before.
7. Consider your results. Was the problem solved? Was it improved?
A problem will not always have a binary answer of “fixed” and “unfixed.” In some scenarios, there is room for improvement without fully solving the problem. This can take the shape of an intermittent issue happening less often, a slow connection being faster, but not ideally so, or only one of several problems being fixed.
8. If the problem has not been solved, return to step 4 until a solution has been found or all possibilities have been exhausted.
As I noted in Step 7, a problem may or may not always be completely solved, but it may be fixed to the point of satisfaction, or even just usability. You need to determine whether you should leave good enough (or at least “better”) alone or continue trying to make something better. If the next step you might take is destructive and risks making the problem worse, you might consider letting the troubleshooting process come to a close. If the problem is not solved or if it can reasonably be improved further, then repeat the process.
Though the troubleshooting process seems much more rigid than tinkering normally would be, using a methodical approach in a stressful troubleshooting situation can help you achieve better results and maintain some of the tinkering joy, even as you work to solve a serious problem.