You read through the code. You read it again to make sure you understand what it’s doing. Your left eye starts twitching. You read the code a third time. “WTF was wrong with the person who wrote this?” I hate how often I react this way. It’s a quick default that’s hard to reset — immediate annoyance as if the developer or engineer responsible for writing whatever I’ve come across was scattering landmines.

It’s two in the morning. Your phone has vibrated itself off the nightstand — dozens of notifications, none of them particularly helpful. You stumble into the living room, stubbing your toe on the couch. You curse and hobble over to where you left your laptop. It wakes from sleep mode. You login, pull up monitoring. The app is down. Everything is down. The world is on fire and you have no idea where to start throwing water.

You spend the first part of your career implementing simple designs, because that’s all you know how to do. It’s what you learned on a blog. It’s how the senior engineer taught you. You get frustrated by how long it takes you to do stuff that others around you are flying through. You feel like you’re drawing in crayon. Then, as you learn, you get faster and bolt on complexity. Checkbox here, change from the default there.

If you’re a DevOps engineer who is constantly fighting fires and trying to keep your head down, it’s easy to get stuck in a rut of “You ask, I build”. Heck, it’s easy to think that way even when everything is running smoothly. But that’s not what the job should be, or at least what the job can be. Not asking the right questions leads to more firefighting down the road and smooth operations devolving into mediocrity.

A few years ago, if you would have asked me to define DevOps, my answer would have sounded something like “Mumble mumble automation, mumble, automation, mumble mumble, infrastructure-as-code, mumble mumble, strategery.” Thinking that DevOps equated to automation had mostly to do with the fact that most of the DevOps people I talked to and articles I read really only spoke about automation with only indirect references to anything else. Implementing automation is definitely a part of what it means to be practicing DevOps, but it’s maybe 5-10%.

Prior to the last week, I hadn’t done much with Puppet. Most of my config management experience is with Microsoft tools and Ansible. Puppet was a contender the last time I was involved in picking a CM tool, but was ultimately ruled out. Compared to some of the newer CM tools, it felt clunky and, compared to Ansible specifically, the Puppet documentation sucks. A week in, I can’t say that I’m a fan yet, but I’m starting to see some of Puppet’s strengths more clearly.

It is 104 degrees, 120 on the sidewalk, but less humid than I am used to, which is nice. As always, Las Vegas’ kaleidoscope of people is disorienting. It’s one of the most interesting places in the world for people watching— desperate to prove Bill Langewiesche’s “You should not see the desert simply as some faraway place of little rain. There are many forms of thirst.” I am always uncomfortable here.

A few years back, in a sidebar discussion at a tech conference, one of Netflix’s engineering managers asked me if I was using any automation tools at work. I said, “Not really. It’s a small environment and we’re not delivering any web apps that require automation for scale.” She gave me an amused/sympathetic look and replied, “Dealing with scale isn’t the only reason to automate things.” It wasn’t condescension; she was being kind — dropping some knowledge, but I didn’t know how to respond.

I spent a lot of time being angry when I started my career. My employers and bosses frustrated me. My coworkers frustrated me. End users, customers, everyone frustrated me. I got angry about decisions that made no sense to me. Most of my complaints fell into the theme of: “If I was in charge, we’d never do X.” If only they’d asked me first. If only I was the boss.

Some apps are easy to move to the cloud. Some apps are born there. Some… aren’t. A scenario a lot of us see as we migrate workloads is that we end up with shiny automated hotness in the cloud and then a bunch of old busted apps running on-prem. Alternatively, if you work with more traditional IT and don’t know where to start, migrating workloads can feel daunting. Designing for cloud requires a lot more abstraction than on-prem.