Developer Experience

Measure the loop, not opinions. Cold start time for the dev server, hot reload latency, type-check time in the editor, the full CI duration, and time from opening a PR to a clickable preview. These are concrete, and they are what people actually experience. Complement them with a periodic developer survey, because friction that nobody measured is still friction — SPACE exists precisely because throughput numbers alone mislead.

The usual wins, in rough order. Dev server startup: Vite's native-ESM approach makes it near-constant regardless of project size, which is transformative on a large codebase. HMR that preserves state: reloading the page and re-navigating to the broken state is the most common invisible time sink. Type-check speed: project references and skipLibCheck keep the editor responsive; a laggy editor is a tax on every keystroke. CI duration: remote caching and affected-only builds, which usually cut the majority of the time. Preview deployments: they shorten the review loop more than any local improvement.

Onboarding is the honest test of the whole setup. Time from clone to a running app with realistic data is a single number that captures the health of scripts, documentation, environment configuration and seeding. If it is a day, it is a day for everyone joining, forever, and it usually means the setup is undocumented rather than complex.

Reduce decisions. Formatting, commit conventions, folder structure, and library choices settled once and enforced by tooling remove a small tax from every change and a large one from every review.

Error messages are DX. A build failure that names the file, the line, and the likely fix saves the time that a generic stack does not. Custom lint rules and schema-validated environment variables both pay off here — "missing DATABASE_URL" at startup beats undefined at 3am.

Two cautions. DX work has diminishing returns: shaving a hundred milliseconds off a fast build is not worth a week. And DX is not an end in itself — the goal is shipping, so the test for any investment is whether it makes the team faster at delivering, not whether it is pleasant.

Compounding is the argument: a loop run fifty times a day, sped up by ten seconds, returns most of an hour per developer per week, and the effect on willingness to refactor and test is larger still.

It is also a visible seniority behaviour — noticing and fixing shared friction rather than working around it privately.

• Measure the inner loop: dev startup, HMR latency, editor type-check, CI duration, time to preview.
• Pair the numbers with a survey; throughput metrics alone miss real friction.
• Biggest wins: fast dev startup, state-preserving HMR, responsive types, cached CI, preview deploys.
• Time from clone to running app is the single best proxy for overall setup health.
• Settle formatting, conventions, and structure once and enforce them in tooling.
• Treat error messages as a product surface — name the file, the line, and the fix.
• Stop when returns diminish; the goal is shipping, not a pleasant build.