Anyone who's been in IT for more than 10 minutes knows that troubleshooting is a huge part of the job. Some item -- it doesn't matter what -- breaks in a new and entirely unexpected way, and by default, it's up to you to get it fixed. It doesn't matter how many books you've read, how well you know the user guide, or what you ate for breakfast. What matters is how quickly you can connect the dots and wiggle your way out of the problem.
No book or teacher can magically pour deductive problem-solving skills into your head. What works is lots of experience falling flat on your face -- and lots of pounding your head on a desk until you solve a particularly intractable problem. I've learned the most from incidents during which I've broken something so thoroughly that I have absolutely no idea how to put it back together again. That's a gauntlet no one wants to walk, but everyone does. The more painful the experience, the more likely you are to get wiser.
Nonetheless, received wisdom has its place -- especially if you work in a siloed IT environment or specialize in a particular domain and need to broaden your knowledge. You'll thank yourself the next time you're so lost and alone in the weeds even Google can't help you.
How to use a protocol analyzer
If you haven't used a protocol analyzer before, it may sound like a tool that only a specialized network engineer would need. Because literally everything is networked in some fashion, knowing what actually makes networks tick -- what's in a packet and how to see what's really happening when a networked application says, "Sorry, I can't do that, Dave" -- can be amazingly useful for just about anyone.
In fact, being able to understand what's going over the wire is arguably much more useful for programmers or analysts than it is for network engineers. Plus, it's actually fun. If you haven't tried it before, get Wireshark and mess around with it. Telnet into something and replay the telnet session. (See that password? That's why we use encryption.)
If you have a VoIP phone system, mirror the port on a phone and play back the audio of a phone call from the raw packet stream. Or if you want to be shocked and saddened, see how incredibly chatty your PC and home network are -- especially if a few game systems or a networked TV are kicking around.
If you keep at it long enough that you have a rough understanding of most of what you're looking at, troubleshooting the next weird network problem will be that much easier.
How to pick apart a Web application
Of all of the problem descriptions I get, my least favorite is "It's slow!!" This can apply to any type of application, but it's particularly infuriating with Web apps. You can go down the line from the network engineers to the server admins to the database admins to the application developers, and every one of them will say everything is fine. But that doesn't help those poor users staring at a blank screen for five seconds every time they click a link.