Development & Code · master area
Developer Experience (DX)
The inner loop — clone, install, run, change, see — is the cost paid every minute of every cycle. Friction here compounds, silently, across years. Sharpness here compounds the other way.
Owners: Tech Lead, Developer Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Every cycle's small wins compound.
Where it lives in the chain
- How We Build · Service composition and DX — the canon
How to do this
- Practice — the README's "run locally" instructions are dated and tested. A new dev follows them on day 1; if they can't, the README is the next bug.
- Practice — type safety is on by default. Lint warnings are errors; warnings nobody fixes are noise the team learns to ignore.
- Practice — hot reload, fast tests, fast type-check. The inner loop is under 5 seconds; anything slower changes behaviour (devs stop running tests locally).
What good DX looks like
| Step | Good | Smell |
|---|---|---|
| Clone → running | Under 10 minutes, no DM needed | Day-long onboarding, multiple .env requests, "ask Esti for the secret" |
| Save → see | Under 2 seconds | Manual restart, full rebuild, browser refresh |
| Run unit tests | Under 30 seconds | Tests skipped because they're slow |
| Type check | Continuous in IDE | "Run tsc to see if it compiles" |
| Lint | Auto-fix on save | Manual reformatting, style debates in PRs |
The Tech Lead owns DX the same way the Designer owns the design system. Both produce invisible compounding. The team that has good DX produces more cycles per quarter — not because anyone is working harder, but because the cost of being a developer in this codebase is lower.
Related crafts
- Environment Management
- Trunk-Based Development — fast inner loop enables fast trunk discipline
- Refactoring — paid for by good DX