“How To Revolutionize Your Personal Tech Development and Skyrocket Your IT Career! #ExpontentialGrowth”

Disclaimer: Clickbait title is a red-herring. This post should actually be called something a little more modest and humdrum, like, “Learning Strategies”. The opinions contained herein are highly subjective, and may be of limited relevance to anyone who isn’t specifically me.

Setup

What are the most effective learning strategies for someone transitioning into the IT industry? How can one work-smarter-not-harder when it comes to developing their fundamental skills in…

• Networking
• Cybersecurity
• Troubleshooting
• Scripting
• etc.

YouTube tutorials? Home Lab projects? Go back to college?

There are, of course, some underlying principles for learning any skillset as quickly as possible: focus on specific, actionable subjects; take good notes and review them at intervals for memory retention; get practical, hands-on experience as soon and as often as possible; and so on.

So, assuming those sorts of principles are a given, what are the pros and cons of the various approaches to learning that are available to a new helpdesk technician?

Strategy #1: Working Tickets 🎟️👷‍♂️

Photo by Sebastian Herrmann on Unsplash

Take a call, talk to a client, try to isolate their issue, Google their Outlook error, try a series of repairs until one makes the error go away.

Get an email, read over the complaints, isolate the issue, try to access their firewall, fail, call their ISP, be informed of a multi-continental internet outage due to a coterie of state-sponsored orcas chewing through all the submarine cables. Escalate.

Working tickets has a well-earned reputation for being both necessary, and a grind. You are on the front lines, poking your head above the foxhole to explain to a charging hoard of understandably irritable end users that the latest Microsoft Teams update broke it for everyone, not just them. But, at the same time, tickets are invaluable for developing troubleshooting muscle-memory.

Ticket work is the exact opposite of “book-learning”. You are getting your hands dirty, and proving your ability to actually solve problems (as opposed to theoretically being able to fix stuff). In addition to developing one’s troubleshooting instincts, it teaches you people skills, specifically how to interpret questions from non-technical clients.

Still, in terms of a learning strategy, ticket work has its downsides. Any material about bigger topics (e.g. TCP/IP, or AWS storage options, or AD replication) has to be digested in a fragmented fashion. You only get snippets of a bigger picture; piecemeal, ad hoc.

That’s because personal development isn’t the focus of ticket work. Even if you do a good job, you might never get to know what exactly fixed the issue, what specifically broke, or how to avoid it the next time around. Following the correct troubleshooting process might just result in escalating the ticket due to time constraints, or privileged access.

The value of ticket work will also depend on where you are vs. where you want to be. If you want to develop general IT skills, but work as technical support for a specific, proprietary software, that’s a problem. If you’re a generalist at an MSP, but want to pivot into an area of specialization, that can be difficult as well.

Strategy #2: Degrees 🧑‍🎓🎓

I don’t have any personal experience with traditional education, in terms of IT. I’m one of those liberal arts transplants.

The value of a CS degree for an IT career seems to have a very mixed reputation. Some of that skepticism is probably justified, and some is probably jealousy. A new tech with a CS degree might be a “paper tiger”, over-qualified in theory, but helpless when faced with actual problems to solve. On the other hand, that degree might be a required qualification for a higher paying management position.

Personally, I’d probably only want to go back to school for a CS degree if an employer was paying for it, and would consider me for a promotion once I had it. And if I was ever planning on taking classes solely for their value as a learning strategy, I’d absolutely want a detailed curriculum before signing up. Unless 95% of the material for the course was specifically targeted at exactly the skills I wanted to develop, what is the point?

On the other hand, if I was a college freshman looking for a major, sure, it might as well be computer science. But I’d expect both the pros and cons of that experience to come from the exposure to a broad range of technologies. I’d expect to get frustrated when cramming for a quiz on, for example, Object Oriented Programming when I intend to go into Cybersecurity, or for a semester on Stack/Heap memory allocation when I am only interested in UX Design.

Strategy #3: Certifications 📜📑

I have lots of experience with this category. Just like a formal CS degree, the primary value of certifications is to get hired or promoted. Education is clearly an afterthought compared to the value of the piece of paper, and the proficiency it claims to represent.

But since we have to spend time on them, anyway, they might as well be considered for the secondary benefits of actually developing technical skills.

To put it bluntly, if I wasn’t getting the piece of paper, I’d never invest my time on studying the exam topics for a cert. 100 hours spent memorizing objectives for the CompTIA Net+ could be much better spent watching high-quality YouTube tutorials and recreating those projects in a home lab.

Cert exams are frustrating. A lot of the material is either 1) Too superficial to be applicable 2) Designed for testing purposes, not real-life application or 3) Diluted by brand-specific marketing, buzzwords, and sales pitches. The exam material might also be woefully out of date, even when the vendor wrote the test themselves (Microsoft).

Earning a cert, at best, proves grit. At worst, proves cheating or memorization abilities. Working through entry level certs like the CompTIA trifecta will probably introduce a new tech to a lot of topics, which is great, but if that was their primary purpose, they would do a better job of it.

Strategy #4: Goal-Oriented Home Lab 🔬🥼🖥️💾

Big fan of this approach. It is incredibly satisfying to spend a few hours of free time implementing VLANs, or GPOs, or even just carefully reading through documentation until I understand something that has been confusing me for weeks (I’m using the term “home lab” as a catchall for targeted study sessions and projects, as well as actually implementing home servers, and so forth).

A home lab is basically the exact inverse of degrees / certifications. It might have some value on a resume, but it very well might not even be considered. But you don’t have to wade through a bunch of irrelevant nonsense to learn what you actually want to learn. And, you don’t have to shrug and move on without a through understanding of the topic, as you might while working helpdesk tickets.

Cons: A home lab requires self-motivation, eats up free time, and might cost some money. But in terms of effective learning strategies, it is an easy S tier. Its only competition, IMO, is its existential crisis of a cousin…

Strategy #5: Rabbit Hole Home Lab 🐇🕳️

I’m differentiating these two types of “home lab” approaches because they are both so important, and in such different ways.

If the home lab project is Goal-Oriented, you’ll keep pushing through to a resolution, possibly at the expense of some uncertainty along the way. You get something to work, similar to a helpdesk ticket, and you definitely have more time to educate yourself on the how and why…but, at the end of the day, if you want the NAS installed and operational, you have to just get it done.

If the home lab project uses the Rabbit Hole approach, you’ll learn a lot, but might very well make as much progress as Achilles chasing the tortoise:

1. You start reading through a tutorial or some documentation, and stop once you run into another topic you don’t understand.
2. Then, you research that topic. If that answers your question, great, you can move back to the original document.
3. Or if, as so often happens, the second topic introduces ANOTHER thing you’ve never heard of, you Google that…and so on.

Results vary. For me, personally, if I start reading through a 1000 word guide on how to configure a firewall policy, I’ll most likely make it 15 words in before I encounter an acronym I’m only vaguely familiar with. And, admittedly, it can be frustrating to try to answer one question and, after hours of hard work and perseverance, have ten more questions to show for it.

Still, investing that time results in personal growth, regardless. And - theoretically - the rabbit hole will grow more shallow and less labyrinthian over time, as the effort invested in any of these learning strategies pays off in expertise.

Honorable Mentions 🙏

• Project Work
  • Instead of working tickets, being assigned to help research/design/implement/maintain a new system.
  • Should provide a lot more time to develop expertise and fill in gaps in understanding, compared to working helpdesk tickets.
  • For someone in my shoes, this is a mid-to-long term career goal. Project work might come sooner for, say, a veteran with a CS degree applying to specialized Cybersecurity roles.
• Tutoring
  • I’ve never hired a tutor, but the platforms are out there. Since the end goal of learning technical skills is to make money, it would probably require a special situation to justify paying someone to teach you a new skillset. And the struggle of learning new material is usually essential to the process of actually understanding it, anyway.
  • I’ve also never worked as a tutor, but it is easy to see how valuable that experience could be. Could be a profitable side gig. And learning something well enough to teach it is the core of the Feynman Technique. Developing the skills to not only fix the problem, but to explain how you fixed it, and why it broke, could be invaluable; the tech world is particularly full of experts who couldn’t articulate their process to save their life.

---