Stripe pulled a Gartner 2 years ago and did a survey of the C-suite around the world: what are devs doing that works and does not work. Its main point is while executives think getting more developers is the most important thing, in actuality their data showed how developers are utilized is the #1 thing executives should do instead.

It’s making the rounds on Twitter b/c Charity Majors, a smart & famous no-nonsense engineering leader, rages in favor of fast Continuous Delivery pipelines as that key productivity enhancement among many. She posits engineering leadership’s sole goal should be to increase our, developers, productivity.

As someone whose skill set lies in writing code, and not in Ops/Unix/CD, I have a large swath of passionate, mixed emotions about this, as it’s just 1 thing that makes my job hard without the skill set to easily remedy. Specifically, there is a huge gap, in both capability and time between running “aws lambda update-function” on the commandline which takes 4 seconds, and running a pipeline in TeamCity/Jenkins/CloudFormation, etc that takes 12 minutes from start to finish. Yes, it shouldn’t take more than 4 seconds to see 1 line of code in a dev environment. But what type of dev? No tests? No linting? No security compliance? No rollback? Configuration drift suddenly ok?

Back in my consulting days, I tried to come up with a priority framework for other consultants who were brought in to fix a gigantic mess. The article itself is a mess, but that’s ok, it was just an experiment of mine. The point is a fast, repeatable build should be your #1 engineering priority.

The first 4 were for the human element of consulting, but once you’re past gaining understanding of what your client wants, who the players are, and you’ve gained their trust, your #1 priority as the consultant is to fix the build. Nothing has been more productivity destroying in my career as a slow, unpredictable build. It’s part of Continuous Delivery because you often have a server performing the same build commands a developer would be doing locally. If it’s slow on your machine locally, it’ll be even slower on the CD server. It’s why I’m extremely hostile towards complex builds in JavaScript web development; they do not age well.

Anyway, report is worth a glance around the numbers, and Charity’s twitter threads are always full of insight. Even if you’re like me and have zero intention of ever going the engineering leadership role and want to stay Individual Contributor, her perspectives on how they enable you to do your job is quite interesting.