I may have gotten into console gaming at the end of the '80s and started branching out with personal tech in the late '90s, but I didn't get my first paying IT role until 2012. For as much as I knew, I was about to get hit with a firehose of knowledge over the next several years.

As many do, I got my start in a helpdesk role. This one happened to be at a local hospital. I got my first few days of training from a more senior co-worker, met my day shift coworker once before they went on medical leave, and then got tossed into running the shift solo for the next couple of months. As much as it was a struggle, it was an excellent way to learn by immersion. Not only was I learning the hard skills to help keep users working, but it was also invaluable in building a customer service attitude and mindset. For as many users that are pleasant and cooperative, you'll eventually run into some that aren't. They don't want to tell you what the problem is, they don't want to help you figure it out by telling you what they've experienced, they just want you to make it work. These are the users that push your diplomatic abilities to new heights.

So what about those hard tech skills? My time in helpdesk taught me a wide range of things. I got comfortable with Microsoft Office, particularly Outlook 2010. I learned about VNC for remote assistance of users, and RDP for remote management of servers. Even though having a print server was a cool concept at first, I discovered that printers suck way more in an enterprise environment than they do at home. I replaced a lot of phone cords, network cables, keyboards, and toner cartridges. I learned how to pull Excel reports from our mainframe system, and got pretty good about helping users troubleshoot applications that I didn't have credentials for and wouldn't be trained to use.

When you pick things up quickly, don't constantly ask for help on things you've done a dozen times, and show up to work consistently, people notice. After around a year and a half, I began training with a more senior coworker to be a workstation tech to help with replacing hundreds of aging PCs and laptops. Within another six months, I was completely out of the helpdesk. This introduced me to imaging technologies like Acronis, managing user and device objects in Active Directory, and the "joy" of warranty service from hardware vendors. I also learned to configure and replace printers in conjunction with the previously mentioned Microsoft Print servers, install, test, and replace rackmount UPS units and move IT equipment for entire departments from one location to another for various reasons. I shadowed the phone guy and learned the basics of an Avaya phone system.

Fast forward about two more years and there was an opening for a sysadmin role when a coworker left to work elsewhere. I wanted it. I had no solid idea what it entailed outside of the vague job description. I was ready to ask my manager for it. But...

It was offered to me before I got the chance!

I was completely caught off guard and incredibly proud of myself. There's no doubt in my mind that this was accomplished by being curious, teachable, reliable, and willing to take on tasks even if I barely knew where to start. I think some of our users had readjustment fits when they couldn't call the helpdesk and ask for me anymore, and I would occasionally hear "Oh, you do still work here" when I would venture out into the halls, but there was growth and skillz to be had.

One of the first new skills I acquired was racking, cabling, and provisioning bare-metal servers, and I deployed 50+ over a few years. I reviewed and set up a PoC for a thin-client management system that moved into production and created all of the endpoint configurations to go with it. I took over server backup and restore activities which were on tape(!) at the time, and later became the administrator for the disk-based backup system that we transitioned to. I managed Windows updates for user workstations with Windows Server Update Services (WSUS), learned to create GPOs for large-scale configurations, and replaced Server 2008R2 domain controllers with Server 2016 allowing for a forest functional level upgrade. Best change? Removing the 15-minute replication delay between AD sites via ADSI Edit. No more waiting for password resets initiated at one site to replicate to another meant less repeat calls to helpdesk.

My love for automation also started here; we adopted some commercial software that helped with deploying software silently over the network and I spent weeks scraping for silent install parameters and building deployment packages for everything I could. I deployed things that I wasn't supposed to be able to and used scripts mid-deployment to fix things that installers broke. It was also great for non-Microsoft patch management.

I managed antivirus and XDR platforms, and learned enough networking to configure switches for new sites and replacements. I helped with day-to-day Exchange mailbox management and did compliance exports for legal, helped maintain user account lifecycle management, and increased security group usage for streamlined file server permissions.

Although I learned a wide variety of technical skills over the years, my greatest accomplishment was earning a level of trust that few others had. Outside of managers that had been there for a decade or more, I was one of the first to be trusted with a handful of things that were considered too fragile for anyone to touch. I also found that my input was being valued and considered in situations that would have traditionally been top-down decisions, and I enjoyed a level of autonomy in getting things done that was unheard of.

Pro-tip: learn communication skills and be personable. If you work in IT, you work in customer service. You will likely work with internal users, project managers, and/or customer/vendor contacts.

Pro-tip 2: learn the technical things, but relate them to the bigger picture and understand how to support and improve the organization.

That's enough for this post, subscribe below if you want email notifications for future posts!

My interest in technology kicked off early; I had the 8-bit NES (Nintendo) before I was five years old and burned many hours gaming on that platform, a Nintendo Game Boy, the Sega Genesis, Nintendo64, and the first Sony PlayStation, well into my teenage years. Somewhere during the Windows 95 era, I was introduced to PC gaming and the early consumer internet by way of AOL. Many more hours were burned in parallel playing Doom 2, Descent, and MegaRace and dropping sound effects into chat rooms. Occasionally I miss the ritual of dialing up to connect to the internet and hearing the screech of the modem that's forever embedded in my memories.

Video games may have baited me into this journey, and still provide a rare opportunity to kill a Sunday afternoon, but operating systems and networks set the hook that would eventually turn me into an IT professional. It wasn't long after my family bought its first PC that I discovered they were more than a glorified game console and AOL gateway. I didn't void my first warranty quite this early, but my curiosity sent me through as many menus and programs as I could find.

Old-school pro tip: don't compress your boot drive.

Fortunately for me, I had my own laptop by the time DSL internet became available and file-sharing networks were popular, so I never destroyed the shared family computer. But there was at least once that I had to reinstall Windows due to a severe malware infection. Little did I know I'd give away a free lifetime subscription for tech support to my (and my wife's) family within a couple of years based on what I knew up to this point.

After high school, armed with a job and a little more free time, I eventually learned about upgrading computer hardware and discrete GPU's to enhance the PC gaming experience. At the time it was cheaper to build a gaming rig than to buy one, so I bought one that someone else built for me to split the difference. I would eventually build three or four more for myself and do a little overclocking, too. Those first Intel Core2 processors were SO much fun. Double the stock clock using the OEM air cooler? Yes, please!

As I started spending less time gaming, I spent more time learning. I did some dual-boot trials with Windows and Linux and ran Gentoo Linux standalone for a couple of months before I needed to do a gaming bender and re-installed Windows Vista x64. I'm still not a Linux Admin, but that was a masterclass in gtfo of the GUI and embrace the command line to get skillz. By the way, haters gonna hate, but Vista always ran like a champ for me! I also started learning (consumer-level) networking around this time and even did a little firmware flashing on a trusty 'ole Linksys wireless router to try out the DD-WRT software.

Through the early years, I was essentially testing in prod; I didn't have spare computers and devices in case I screwed up. It was, however, this 'home lab' of sorts that sealed the deal for my first IT helpdesk job. I didn't know anything about troubleshooting at an enterprise level yet, but for every other question that came up during the interview, I answered with "Yes. I can do that." I even got to tell them yes when they asked if I knew anything about AS-400. I'm pretty sure no other interview they had before that, and at least up to the time I left, can say the same.

Since my home lab was prod, I got in the habit of researching, researching somewhere else, confirming it through another source, and then trying things on my own. Or some slight variation of that. It's a bit slower than "F*ck it, send it," but it's a habit that has served me well professionally. I've had relatively few major breakages at work, and my research habits put me in a position to be able to confidently make recommendations even for things I only have a working knowledge of. And now I've seen enough that I know when it's relatively safe to just "send it" and see what happens.

Not-so-old-school pro-tip: Knowing when it's safe to just "send it" also has to account for the people you have to inform if something breaks; some managers are less forgiving of mistakes than others.

Not-so-old-school pro-tip 2: Don't change prod on Friday*.

*Unless you're absolutely, positively 100% sure that it won't affect anyone in real-time, and you can roll it back before it does. And you're an adrenaline junkie ;)

That's enough for this post, look for the next one to read about what I learned once I started getting paid to play with tech!