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.)