DevEx has a branding problem
Saying "Developer Experience" is often heard as "let's spend less time on our application and more time making our engineers happy."
I've seen the eye roll.
Hear me out, though; it really isn't that at all. The outcome of a good Developer Experience is efficiency, not happiness. I mean, it will probably make your engineers happier, but that isn't the point.
The 15-minute-task fallacy
“It only takes 15 minutes.”
Why spend hours automating something that only takes 15 minutes?
“Just get it working; we'll automate it later.”
Automation isn't the goal. Building the application is!
The decision to not codify and systematize your processes adds up over time. At first it's just one or two little things. Pretty soon it's dozens of little manual tasks here and there.
The cost to the team is not just the extra time it takes. It's the periodic interruptions that, like a thousand paper cuts, wears people down and limits their ability to innovate.
YAGNI can create its own kind of complexity
"We don't need that yet."
Maybe. Or maybe it helps us move faster.
Constantly taking the shortest path will produce a disjointed system. One with lots of quirks that not everyone understands.
The hallmark of a good engineer is finding simple solutions to a problem. But what can seem simple in isolation can actually be complex for the system as a whole. A good solution is one that fits in well with the rest of the system, not just the shortest, quickest implementation.
“We'll automate later” is often backwards
Automation implemented early pays you back more over time than waiting.
If you do it now, you can afford to fail and iterate on it. If you wait until later, you're adding risk to an existing system. It costs more. It's harder to do later.
Invest in it now and it becomes leverage for the rest of your project.
What good DevEx looks like to me
- Test environments can be created effortlessly
- Environments are reproducible rather than hand-built
- Automated tests enable continuous delivery
- Configuration applies coherently across services
- Failures are clearly and quickly understood
Everything comes together in a predictable, reliable way.
The common denominator: cognitive overhead
Engineers have only so much brain budget to spend.
The issue here isn't really time, it's attention. A system built on years of shortcuts is a very expensive system, cognitively.
It makes working on the system harder than it needs to be and onboarding new engineers difficult and time-consuming.
A good system has lots of documentation. A great system doesn't need it.
Short feedback loops create leverage
Connect your entire system end-to-end and make the change -> test -> deploy cycle fast and reliable.
The less time your engineers have to wait between those steps, the more your organization gets done.
Before adding more engineers to your team, consider how much time is being wasted on friction and how often it happens. A 15-minute interruption once is better than 10 1-minute diversions.
The uncomfortable part: judgment
None of this is to say that over-engineering isn't a thing. It is, and it can destroy the cohesiveness of your system and burden your team.
But it takes better judgment than saying "no" to anything but building this feature or hitting that KPI.
There's also no formula for when you should and shouldn't build something. But, a clear sign that you've made poor decisions is if you can't make changes confidently. If touching code strikes fear that it might take production down, you haven't invested enough in your automation and testing.
Don't build for a hypothetical future. Build a foundation that makes change cheap.
Why I care about DevEx
Because I like to see teams building great things. Many things. I like to see them get something done and be free to move on to the next thing and not sit there babying their fussy unicorn.