If Running Tests Takes Willpower, They're Too Slow

Tue, 28 Jul 2026 09:00:00 -0500

The layers of feedback

The practices in this series keep circling back to feedback, for a reason: the speed of your feedback loop sets the speed of your learning, and the speed of your learning sets almost everything else about how effective you are.

Feedback loops come in layers, and the right fix is different at each one.

Editor feedback. Compiler errors, go vet, staticcheck, inline warnings. Zero latency, the tightest loop that exists. Investing in it, stricter linting, more complete type coverage, pays back with compounding interest.
Unit tests in watch mode. Sub-second, on the file you just changed. If your unit tests don’t run automatically on save (gotestsum --watch, or your editor’s built-in runner), you’re leaving real developer experience on the table.
Local rebuild-and-run. A change reflected without a full redeploy. Trivial to script with air or reflex, and often just left off.
Integration tests. Should run in seconds, not minutes. A slow test doesn’t get run. That’s not a discipline problem, it’s an incentives problem: a four-minute suite gives engineers a reason to skip it before pushing.
CI. Parallelize aggressively. A twenty-minute pipeline is a morale tax paid on every single PR, and the cost isn’t just the twenty minutes, it’s the context switch of sitting there waiting.

The heuristic: if running tests takes willpower, the tests are too slow. Running them should be the path of least resistance, not a deliberate act you have to talk yourself into.

Developer-Experience on rjrowland

If Running Tests Takes Willpower, They're Too Slow

The layers of feedback