Note: I started writing this post and it quickly grew and rambled larger than I intended. As a result I am breaking it down in to multiple posts.
I’m curious as to how much troubleshooting can be reduced to generic terms. It goes without saying that many parts of troubleshooting are specific. For example, my father worked as a mechanic for over 35 years. He can frequently diagnose automobile problems from a succinct description, yet he was having an issue with the Roku I recently bought him. I power cycled it and it started working again. To me (and I’m assuming anyone reading this) it was second nature. He simply said that he hadn’t thought of unplugging the power, and plugging it back in.
As I think of it, my act was actually POOR troubleshooting. Honestly, I didn’t care if the issue was reproducible. I didn’t care about much of the details. Much of my previous experience led me to the quick resolution.
Granted, “resolution” in this case is rather subjective. In this case it’s a relatively cheap device (meaning my expectation of reliability is relatively low). There was no critical failure – no one’s life hung in the balance of watching Breaking Bad. If the problem recurs on a monthly basis, it’s not a big deal, especially if it is reset by crossing the room, pulling then reconnect the power, then waiting two minutes.
Maybe this is why troubleshooting is hard to generalize. Experience will lead to skipping steps, especially to get to an acceptable triage solution. With that in mind, I would like to cover what I feel are some of the important points of effective diagnosis, and will try to cover this in future posts.
Pingback: Isolation & Simplification in Troubleshooting | AltiBen
Pingback: Clarification of the Problem Description When Troubleshooting | AltiBen