About
Really? Not a one?
My name is J. Paul Reed.
I am “The Sober Build Engineer.”
The nickname was born during an IRC conversation in 2008, wherein my coworkers and I were musing about the existence of such a thing.
Google, at the time, didn’t think it existed.
It’s easy to see why.
Release engineering is a nexus of a lot of people and processes to get bits out the door. Release engineers wear many hats, serve many customers, and are often forgotten about… unless something goes awry and everyone comes to you because the product isn’t shipping.
I’ve been playing a part in this particular movie for over a decade now, falling in love with it on Netscape’s build/release team at the dawn of the Mozilla Project.
Since that time, I’ve been privileged to work on teams shipping everything from “enterprise software” to web browsers to Rails sites. And while each and every product is different, the patterns you see in the interactions of people, tools, and software seldom change.
I truly believe that well-implemented release engineering practices and infrastructure are one of the best ways to increase not only developer productivity, but organizational productivity. This is especially true in organizations that are growing and scaling and realizing that it’s getting harder and harder to ship their software.
Investing in this area is one of the best bangs for your infrastructure-buck, and I’ve seen these wins over and over again when working with the various organizations I’ve had a chance to work with to help “level-up” their build/release practices.
My goal is to present insight into an aspect of the software engineering process few deal with, to make the case that release engineering is something every organization should pay attention to, and to provide concrete ideas on improving your own tools, processes and infrastructure that might be “driving the team to drink.”
Hopefully all of them prove… sobering.
Whichever one it is, the Sober Build Engineer is here to help you simply ship.
Every time.