Nice to meet me

Welcome to my blog, I'm Daniel. This space will mostly chronicle my current and future tech trip. It's partially intended for you, the reader, and partially for my own reference back to things I've done and forgotten. But first... a history lesson!

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!