Someone’s Got to Do It

My first development job out of college was at a big telecom company in the “Software Integration and Release” department – affectionately known as SIR. We built the software loads that ran on giant telephony switches, and on a scale I’d never seen before. Dozens of top-of-the-line UNIX servers ran for hours doing parallelized compilation and linking of millions of lines of code from what was allegedly the largest source repository in existence. The entire toolchain was proprietary: the language, the distributed compiler, the source repository… all of it. Building and packaging a switch load was a fairly labor-intensive process – hence multiple departments devoted to the task. But when I was hired, my manager told me “Our objective is to automate ourselves out of a job.” And that’s pretty much what we did.

It wasn’t considered particularly prestigious work in the company. We were basically regarded as support staff – a necessary expense. However, I had a CS degree from a top-tier university, and my skills were on par with most other developers in the company. At first it rankled a bit to have that second-class status; but I soon came to realize that I was in a position to have an impact I wasn’t likely to have anywhere else in the company. Our team deployed tools and processes that literally saved millions of dollars in developer-hours. We helped rescue high-profile projects that were running up against tough deadlines or production constraints. I developed relationships with senior developers, architects, and managers who valued my role because I reduced friction and helped them get things done.

When I eventually left that department, I moved around the company into other – ostensibly more “serious” – development roles. However, curiously enough I kept finding myself taking on the same sorts of activities no matter where I went. Code needs to be version-controlled. It has to be compiled. It has to be compiled faster. It has to be packaged for deployment and tested and distributed and… There’s an awful lot of work that goes into producing a software application beyond just writing the features. Many developers find that extra work tedious and annoying; but someone’s got to do it. And somehow that someone generally ended up being me – probably because I’d already spent years thinking about questions like “How are we going to deploy this?” or “How can we determine what version of the code built this binary?” or “How can we know our test results are trustworthy?” or “How can we spend less time on process overhead?”

Over time, new technologies and techniques emerged that revolutionized these meta aspects of software development: virtualization, continuous integration platforms, distributed version control, containers, the “cloud”, All-The-Things-as-code, etc. I’ve gone on to other companies and worked with teams both big and small. My day-to-day tools and tasks have changed quite a bit, and my role has gone by many names: release engineering, devops, developer productivity engineering, etc. But fundamentally my objective has remained the same: to improve the lives of developers by helping them be more productive. A former colleague referred to this as being the Alfred to their Batman, and I really liked that metaphor. The Batman catches the villains and makes the headlines. But there are still Bat-vehicles that need refueling. Utility belts need replenishing. Wounds need stitching. Guano needs shovelling (have you ever been in a real cave??). Lobster thermidor needs preparing.

Alfred isn’t the Batman’s errand-runner though. His value comes from knowing what will be required and when it must be ready. He anticipates the Batman’s needs, often before the Batman realizes them – the right tool is already to hand, the right vehicle is already prepared. Alfred is never in the spotlight and never beats up a villain, but both he and the Batman know he’s a critical component of the operation. Because there’s a whole lot of work required to keep the Batman operating… And someone’s got to do it.