About Me

I’ve always been an automation enthusiast. I wrote my first batch file in 1994 to launch DOOM with a two-character command. After taking over the family computer to run a dial-up BBS, I had to expand my scripting skills to automate tasks that handled mail delivery and pickup from FidoNet. Years later, I got a job as a Windows System Administrator.

Being primarily Windows focused, I sat out the early days of the DevOps revolution. When Linux admins were already managing their infrastructure as code with Chef and Puppet, I was still writing batch files, and occasionally, VBScript.

While I’d tinkered with PowerShell, I didn’t get serious until 2010, when I logged into my first Windows Server 2008 R2 machine and saw the blue icon on the task bar, occupying premium real estate. This told me that Microsoft was serious about the shell’s future, and that I had better get going. Once I got my first taste, I never looked back.

Several years later, I watched Jeffery Snover give the keynote presentation at the PowerShell Summit. He spoke about how PowerShell “is all about DevOps”. It was the first time I’d heard the term, so I went home and did a bit of Googling. My search lead me to a book called The Phoenix Project. It had great reviews, but a novel about IT Operations? Ouch. I added it to my wish list, but didn’t read it for several months. When I finally did, I was shaken by the number of parallels to experiences I’d had during my career. The challenges my team and I were facing weren’t unique! Since then, I’ve been doing all I can to not only learn and grow personally, but also to influence culture. I want so very badly to experience the sort of transformative change I read about in the book.

At work, we’ve improved quite a bit. There is constant progress, but there are also frequent setbacks. Occasionally I’ll become frustrated, and question whether we are ever going to get there (wherever there is), but then I look back and see how far we’ve come. It’s not easy to change hearts and minds, let alone decade old processes. It will take time.

Someday, I’ll go to lunch (with developers!) after the fourth code change of the day runs through our CI/CD pipeline and is quietly deployed to our flagship application in production. While eating my salad, I’ll pull out my smartphone and delete a production server. It won’t matter, because the system will seamlessly reroute the traffic to other functional nodes. If load becomes an issue, a new server will be automatically created and deployed. My coworkers and I will sit back, laugh, and marvel about our incredible journey.

Until then? I’ll still be desperately seeking DevOps.