I’ve been involved in, and observed, some recent conversations which have me thinking about why I do what I do. Also, what exactly is it that I do? I was having a discussion about why I enjoy working in the areas I do – which I typically describe as:
- Config management & Deploy automation
- Monitoring infra & app integration
- CI / Build infrastructure
I mentioned that I don’t typically contribute to product features, preferring to focus in these areas. When asked why that was, my first response was – “I suck at algorithms and I never went to school” – both true but inaccurate explanations for why I got where I am. Neither of those things really hold me back from building or contributing to a product. It also doesn’t describe why I’m passionate about what I do.
I’ve never been one to choose to do something because I can’t do what I really want to do. Well, except that if I could jump out of airplanes all day I’d probably do that – totally awesome fun. Instead I rock climb.
I love writing code. I love putting together bits and pieces and building something useful – I’m terrible at finishing coding books because without a practical problem to solve, the incentive just isn’t there. I also get bored pretty quickly. For me, having a stack of things to do is optimal – I move one to the point where I’m blocked and move to something new, I like to focus for periods of time, but then have to switch gears. Occasionally I’ll find something that really gets my attention and it’s like the worst video game addiction – my kids notice, my wife notices, nothing else gets done. That’s rare for me and I am horrible at handling those things other than to just knock it out and get done.
Managing this shifting of priorities & still getting things done is a skill I’ve worked hard to get right. At this point I’m pretty good at it, and struggle working any other way.
Operations has been this for me. In most organizations Ops are the ultimate generalists, both using their own experience to solve problems as well as being adept at engaging other domain experts. We know where the right folks hang out on IRC, we know when to call support and when to just dig in, we learn quickly and are super resourceful. We are exceptionally familiar with the tough problem cycle – initial interest, fear that this is too big, despair that you aren’t going to solve it, the glimmer of hope leading to resolution and awesomeness. I have another post brewing on that specific topic. This isn’t exclusive to Ops, but it’s something you get very used to.
Wait, wasn’t this post about Infracoding?
Yes, the only reason I’m still doing Ops work is because I get to write code. If you were to offer me an Ops job where all I did all day was figure out tough problems for other people to code solutions, I’d tell you to suck it. If you suggest that I can pair with a developer and we can fix it together, I’m happier. If I can get proficient enough to code my own solutions and have other people tell me how to improve what I did, I’d sign up. It’s for this reason that I love the pull request model. I’ve learned from both Sr and Jr team members through PR feedback and it’s a great way for folks to watch and observe what feedback others get.
But along with writing code I get to do other stuff too. Helping to debug strange inconsistencies between monitoring systems – without the ability to code I wouldn’t be able to write the small tools that make testing theories easier. Packaging up and deploying infrastructure, more opportunities to build tooling. Make it easier for Developers to provision their workstations, more coding, more variety. Building networks these days is often pretty limited if you aren’t willing to write code. I know many Ops folks have been doing this for a while, but more and more the % of time an Ops guy spends writing code is increasing, not decreasing. This isn’t universally true, but it’s true of work I am interested in calling Ops.
All along the way, as I get more proficient with coding, as I have become more familiar with patterns you see in production, I can work with developers more closely to help them build better systems. Where developers can definitely get exposed to these same patterns, Ops is pretty directly involved with how things operate in the real world. We get to pull together the resources to make things work and we get to learn in the process. This is the more traditional part of Ops for me, being the guy who helps developers understand the realities of production. But more and more that knowledge gap is closing and Ops are as much an Engineering team as the UI team is. Availability and Agility are features of your product, you have to engineer them in and that requires Developer awareness that is on par with Ops.
Alright Aaron, so what’s your point?
I don’t do feature work because frankly, it seems too focused for me, too specific. Within the Ops role I can go as deep into code as I want but then surface to work on many other things. If I want to go deep on something, there are a bazillion tools out there I can (and sometimes do) contribute to, I can build my own, or not. I get to work with the sharp edges of many tools and find ways to wrap Nerf bits around them. I get to choose when good enough is the enemy of perfection or when perfection is, in fact, the enemy.
I love Ops and every day that role moves closer and closer to awesomeness for me. Although I generally say I don’t know what I want to be when I grow up, I’m pretty sure it’ll look a lot like Ops.
