Stripe and Charity Majors on Developer Productivity
Tags: continuousdelivery, developer, productivity, javascript
Published: 2020-12-20 17:30:25


---
title: Stripe and Charity Majors on Developer Productivity 
published: true
description: Some quick thoughts on the Stripe engineering leadership report around "focus on developer productivity, not more developers" and Charity Major's twitter thread around enabling faster Continuous Delivery as the core aspect.
tags: continuousdelivery,developer,productivity,javascript
canonical_url: https://jessewarden.com/2020/12/stripe-and-charity-majors-on-developer-productivity.html
cover_image: 
---

Stripe pulled a Gartner 2 years ago and did [a survey of the C-suite around the world](https://stripe.com/reports/developer-coefficient-2018): 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](https://twitter.com/mipsytipsy/status/1340556908122411009) 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,](https://jessewarden.com/2012/04/consulting-chronicles-7-the-priority-pyramid.html) 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](https://continuousdelivery.com/) 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.