Developers Are Users Too

You’ve invested in UX because you understand the logic: a customer who can’t navigate your product doesn’t convert, doesn’t return, doesn’t fund your operation. The experience of using the product is inseparable from the value of the product.

Your developers have exactly the same relationship with your codebase. They have goals to achieve, decisions to make, and friction to navigate at every step. Unlike your customers, they’re there. Every. Single. Day.

The accumulated cost of a bad developer experience doesn’t show up in a session recording or a bounce rate but shows up in velocity, in attrition, and in the raised eyebrows when you ask why a “simple” feature took three sprints.

Developer Experience (DX) is a business problem wearing an engineering hat. If you’re not measuring it, or only measuring it in annual happiness surveys, you’re leaving a significant amount of value on the table.

DX isn’t a single thing. It’s the sum of everything that shapes how effectively a developer can do their job. It spans four interconnected areas. None of which live in isolation, and a deficiency in any one of them tends to infect the others.

Do developers feel safe raising problems? Do they have enough context about the product direction to make good local decisions without escalating every ambiguity?

Is there real transparency between the people building the product and the people setting the roadmap? Culture is the foundation everything else rests on. You can have excellent tooling and a poor culture, and the tooling will still underperform. Simply because people won’t maintain it, improve it, or push back when it stops serving them.

The overhead tax on every developer’s day. How long does it take to set up a local environment? How much manual labor sits between a finished feature and a deployed one? How are incidents handled, and does the handling build confidence or anxiety the next time someone ships? Every minute of unnecessary process overhead accumulates to hours not spent on work that actually moves the product forward. These hours are invisible on the roadmap and very visible in team energy levels.

Frameworks, linters, formatters, CI/CD pipelines, test coverage, AI coding assistants together form the equipment your team uses every day. The best tooling gives developers confidence: to ship, to refactor, to hand work to someone else knowing they’ll be able to pick it up. The worst creates uncertainty at every step and quietly trains people to avoid the parts of the codebase that are hard to work with.

This category has expanded dramatically in the past few years, and the stakes have risen with it. An AI assistant working within a well-structured, well-documented codebase is a genuine force multiplier. The same tool working in a messy, undocumented environment produces worse output at high volumne, more confidently and it fills in the gaps with plausible-sounding guesses.

Investing in good tooling and the conditions that make tooling effective are no longer separable questions.

The architecture and organisation of the software itself. Is it clear what each service or module is responsible for? Single or multi purpose? Can a developer understand its purpose, its dependencies, its failure modes, without a two-hour whiteboard session from the one person who built it?

And the question that surfaces in almost every engagement: what’s the actual plan for the legacy? A real plan, with real steps, even if the timeline is long. Legacy without a plan isn’t technical debt, it’s technical drift, and it compounds quietly until it’s suddenly urgent.

Here’s what I find in most organisations: the cost of poor DX is being paid every day, and it doesn’t appear anywhere in the budget.

It appears as senior developers spending disproportionate time explaining the same context to the same new people, because there’s no documentation worth reading. It appears as cautious, slow-moving engineers who’ve been burned enough times by unpredictable deployments that they’re trained to a level of conservatism the business never asked for. It appears as turnover in people who had options and chose to work somewhere less frustrating.

It quietly reduces the return on your engineering investment, quarter after quarter, while the roadmap keeps asking for more output from a system that’s increasingly running on fumes.

The business case for DX investment isn’t philosophical. It’s straightforward.

The people building your product spend more time in it than any customer ever will.

Every improvement to their experience of doing that work adds up. A more solid codebase. Faster delivery. Developers who stay, and bring others up to speed. AI tooling that performs at its potential rather than confidently producing inconsistency. Actually, with a growing codebase, anything not slowing you down is a small win!

If your instinct is that this sounds expensive to fix: you’re right that it takes investment. But you’re already paying for it. You’re just not seeing the invoice.

The good news: most of the highest-leverage DX improvements aren’t expensive. They’re just not on anyone’s roadmap yet.

There’s no off-the-shelf solution here, and there probably never will be. DX is specific to your team, your codebase, your context. But the entry points are consistent.