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.There are many tools that can help with this kind of problem, but a few stand out, including Fiddler, the Web Developer plug-in for Firefox, and the Developer Tools functionality built into Chrome. Next time you run into a Web app performance problem, fire up the timeline functionality in Fiddler or the Chrome Developer Tools, set it to record, and click your way through the page. You may be surprised by the cause of the slowdown.
How cabling and power works
This is a skill that every IT generalist ends up having to know. Whether it's being able to tell the difference between a straight-through and a crossover Ethernet cable, knowing the difference between an L5-30 and an L6-30 power receptacle, or just being able to make an Ethernet cable that's the right length to reach your entertainment center, knowing how network cabling and electrical power work can be indispensible.
How virtualization works under the hood
Virtualization is a fact of life in IT. Businesses of all shapes and sizes have implemented it, and just about every cloud offering is built on it. For the most part, a virtual machine looks, acts, and feels just like a physical one. That's the point. But it's important to realize what's happening under the hood in your hypervisor and how that may change the way you troubleshoot performance problems. Gone are the days when simply opening Task Manager and seeing how busy the server is will tell you what's actually happening.
You need to experiment with your virtualized infrastructure and learn how resource scheduling works -- that is, how the hypervisor divvies up physical resources. Create a process that will nail the processor within a VM (here's a script that will do it if you need one), then place different CPU performance limits on the VM and see how the performance is affected. You'll be surprised by what you find -- and be better prepared if you run into resource contention issues in the wild.
If you lack hands-on experience with virtualization, it's easy to experiment with it: VMware offers a free trial of VMware Workstation that can teach you a lot right off the bat.
How to write useful scripts
Simply put, programming is not just for developers. Knowing a scripting language like Perl or Python, no matter how you decide to use it, can be enormously useful.
The next time you find yourself confronted by a boring, repetitive task, find a way to do what you're trying to do with a script. Chances are, the first few times you do it, you'll take more time to solve the problem than if you had just done it manually. However, before long, you'll have a skill that will grow to become a massively useful asset.
That's just the beginning
Whether you've done all or none of these things, the best step you can possibly take to ensure a happy life in IT is pick something you don't know about and learn it. You may never apply it hands-on, but when you expand your horizons to include stuff you've never worked with before, you'll give yourself an edge you couldn't get any other way. Hey, it's a new year. Why not make it a resolution?