On developer productivity & other things
Or, rmurphey starts a newsletter.
Hi. This is my newsletter. For now, it’s about developer productivity — forever, it will be about tech, nothing terribly personal or overtly political.1
If you’re interested in developer productivity or just what I’m spending my brain time on these days, feel free to follow along.
In the summer of 2022, I posted a thread on Twitter about the project I was working on at the time: our small team was working to understand and improve the experience of software engineering at Stripe.
Our goal was to improve “developer productivity.” I put the words in scare quotes here because I challenge you to find five people who will define developer productivity same way. And let’s be honest, some people hear the words and all they think of is this:
Still, it’s clear in my head that I’ve been working somewhere in this space since long before I knew it had a name — I mean, the first software I wrote for money was a perl script to let me leave my newspaper job at 1 a.m. instead of 1:30 a.m. The power of code to make toil go away has always fascinated me, perhaps more than the power of code to make things.
Of course, that’s not quite what we mean by developer productivity — devops became famous for toil reduction, and perhaps SRE after that, but developer productivity is something different or bigger or adjacent or at least part of some elaborate Venn diagram.
Perhaps developer productivity is the platformization and productization of devops: reducing toil at scale via a central internal effort or via a third-party SaaS offering, from which all2 product development teams derive benefit.
But developer productivity isn’t just a thing you do; it’s a thing companies yearn to measure. If you can measure it, you can change it, right? Show me a company that doesn’t want to change the ROI they’re getting on one of the most expensive inputs to product development: people.
In more than two decades of working somewhere near this space, and nearly a decade focused specifically on increasing the productivity of software engineers, I keep landing here: Developer productivity is a function of fundamentally human actions, inputs, and outputs, and the work of understanding, measuring, and improving it necessarily spans people, process, and technology.
So that’s what I’m going to write about, for now, maybe once a week or so, maybe more often, we’ll see. If that sounds interesting to you, you know what to do.
For some definition of “all.” There will always be teams that need to do their own thing for valid reasons.