Ok, I know I don’t normally post about “non-technical” stuff, but this is one that EVERYONE should read. At least, everyone that is required to help solve problems of any sort, especially Network admins, IT Managers and Staff, and Support folks at a minimum, if not all engineers and just about everyone else. This post is about Troubleshooting. Yes, I know, a boring topic, but one that far too many of us have forgotten the basics of. We all solve problems in our daily lives, and as a result we tend to think that we are good at it. Well, the truth is, we aren’t good at troubleshooting, especially when it comes to solving complex problems (e.g. networking problems, IT issues where someone brings the machine in and says “it doesn’t work”, etc.). But by practicing and some basic fundamentals, we CAN be good at troubleshooting.
The Nerd Guru has an excellent Introduction/Refresher on Troubleshooting and it happens to be an entertaining read as well (with a site named “Nerd Guru” would you expect anything less than at least one summarization of the plot of Start Trek II to make his point?).
One of the most important things to do BEFORE you actually start any real troubleshooting is to define the problem. The most common mistake I see when people are trying to resolve some issue is that they don’t take the time to articulate exactly what the issue is in the first place. Here is an example:
User: “My computer doesn’t work.”
Admin: “What did you do to it?”
User: “Nothing.”
Admin: “Liar, you must’ve done something.”
User: “Really, I didn’t. I came in to the office, sat down, and tried to use it, and it isn’t working.”
Admin: “Ok, I’ll come to your cube and take a look.”
Notice anything wrong there? The first question the Admin asked should have been “what exactly do you mean by that?”. If he had, the User would have told him that he couldn’t log into email because it didn’t recognize his password. By narrowing down the problem the Admin could have resolved it remotely, without having to actually visit the User’s computer. By not asking any questions about the exact problem, the Admin not only wasted a bunch of time, but will also be pretty angry when he gets to the User’s computer and realizes that the computer is fine and the User’s password just needs to be reset. The Admin will leave thinking the User is an idiot and the User will be thinking that the Admin is a condescending jerk.
The point is that before doing anything else, you need to take the time to identify what the problem REALLY is. A good reference that makes this point pretty well and gives you some example questions to ask is Cisco’s System Troubleshooting Methodology. This is a very useful guide even if you don’t have any Cisco gear.
If you aren’t convinced about why you should spend some time taking a quick refresher on troubleshooting, I highly recommend you take a look at The Universal Troubleshooting Process. This site makes an excellent case for why you should define a troubleshooting process and practice it regularly, and it gives you lots of tips on troubleshooting and troubleshooting methodology. Brushing up on troubleshooting will save you time, money, and effort, and will make you look smarter and harder working in the eyes of your colleagues.
Links:
Troubleshooting Techniques [The Nerd Guru]
System Troubleshooting Methodology [Cisco]
The Universal Troubleshooting Process [Troubleshooters.com]






































I found this tool the other day while reading a post on
I am. I love multiple monitor setups. I have for a long time. At one point I had three 21″ monitors and a 14″ laptop all in a row, and I loved it. These days, I’ve ditched the humongous 21″ CRTs for a single 24″ Dell LCD aside my 15″ MBP, but sometimes I really miss the wide open space of that massive 4800×1200 desktop. I’m using a Mac most often these days, and it is amazingly intelligent when it comes to switching back and forth from dual monitors to the single laptop screen, but back when I lived in Windoze land, I would occasionally get some weirdness when I switched from dual monitor more to single monitor mode, and an application or two would get lost off the edge of the screen. At the time, I usually futzed around with things for a while until either giving up or successfully performing the magic keyboard and mouse incantation to get my screen back, but if only I had had