Developer experience (DX) engineering is the practice of treating your own engineering team as a product's users. Every unnecessary manual step, flaky test, unclear error message, or multi-hour local setup is friction — and friction compounds across every engineer, every day, for the life of the project.
The core ideas
- Golden paths: a well-documented, well-supported default way to do common things (start a new service, add a feature flag, deploy a change) so engineers aren't reinventing decisions every time.
- Self-service tooling: engineers can provision what they need — a database, a staging environment, a new repo — without waiting on another team.
- Internal developer platforms: the layer that makes golden paths and self-service actually work, instead of living only in a wiki page nobody reads.
- Fast feedback loops: the time between making a change and knowing whether it worked, kept as short as realistically possible.
Where to start if you're small
You don't need a dedicated platform team to practice good DX. Start by instrumenting the most common painful moments: how long does it take a new engineer to get a local environment running? How long does CI take? How often do deploys fail for reasons unrelated to the actual change? Those answers tell you where to invest first.
Onboarding and documentation
- A new engineer should be able to get a working local setup from documentation alone, without pinging someone on Slack.
- Document the "why" behind non-obvious decisions, not just the "how" — that's what prevents the same debate from happening every six months.
- Keep documentation close to the code it describes, so it's more likely to get updated when the code changes.
CI/CD as a developer experience problem
A slow or flaky CI pipeline is one of the highest-friction things in a codebase, because every engineer pays that tax, every single day. Investing in CI speed and reliability is routinely one of the highest-leverage DX improvements available — more so than almost any individual developer tool you could buy.
Measuring improvement without vanity metrics
| Don't rely on | Why | Measure instead |
|---|---|---|
| Lines of code shipped | Rewards verbosity, not value | Lead time from commit to production |
| Number of tools adopted | Tool count isn't an outcome | Time to a working local environment |
| Tickets closed | Easy to game, doesn't reflect difficulty | CI pipeline duration and flake rate |
| Self-reported happiness alone | Useful signal, but not sufficient on its own | Deployment frequency and change failure rate |
If improving the developer platform is always the thing that gets deprioritized for the next feature, it never happens. Treat a portion of engineering time as a standing investment, the same way you'd budget for security or reliability work.
Want a second opinion on your team's delivery speed?
If something about your engineering workflow feels slower than it should, tell me where the friction is and I'll help you figure out what's actually worth fixing first.
Let's talk →