Developer Burnout and the Illusion of “Best Practices”

Burnout in software development is rarely caused by hard problems. Hard problems are engaging.

What exhausts people is a different category of work: process for the sake of process, standards enforced without rationale, and the slow accumulation of overhead that exists to signal rigor rather than produce it.

Best practices sit at the center of this. Not always — but often enough to examine carefully.

What "Best Practice" Actually Means

The phrase implies a settled conclusion: someone, somewhere, evaluated the alternatives and this one won. In reality, most best practices are patterns that worked in a specific context, at a specific scale, inside a specific organization, and were then exported without their conditions attached.

What arrives at the next team is the prescription without the reasoning. Follow it and you are professional. Question it and you are difficult. That dynamic — compliance rewarded, inquiry penalized — is where the exhaustion begins.

The Overhead That Accumulates

Best practices rarely arrive alone. They travel in clusters, each one reasonable in isolation:

• Pull request reviews with mandatory approval counts regardless of change size
• Test coverage thresholds enforced by CI, independent of what is actually being tested
• Sprint ceremonies retained long after the team stopped finding them useful
• Documentation requirements that produce documents nobody reads
• Architectural review boards that slow decisions without improving them

Each item on that list was, at some point, a genuine solution to a genuine problem.

What persists is the form, not the function. The team absorbs the cost and the original problem it solved either no longer exists or was never present in the first place.

The deeper issue is what best practices do to engineering judgment over time. When the answer to "why do we do this?" is "because it's best practice," judgment atrophies. Developers stop evaluating tradeoffs and start checking boxes. The work becomes procedural.

Procedural work is draining in a specific way. It is not difficult enough to be absorbing and not simple enough to be effortless.

It occupies the hands while leaving the mind with nothing real to engage.

That is the texture of a large fraction of what causes burnout — not overwork in the conventional sense, but underuse of the capacity that drew people to the work in the first place.

Organizations That Mistake Process for Safety

Some of this is structural. Process accumulates in organizations because process is legible and judgment is not. A manager can see whether the pull request was reviewed by two people. They cannot easily see whether the review was substantive. So the measurable proxy gets enforced, and the thing being proxied quietly degrades.

Developers inside these systems learn the lesson quickly. What gets measured gets done; what gets done is the measurement. The gap between real quality and performed quality widens, and the people who notice that gap — who care about the difference — are the ones most likely to burn out. They are doing two jobs: the visible one and the actual one.

The alternative is not the absence of standards. It is standards that carry their reasoning, that can be questioned without social cost, and that are retired when the context that justified them no longer applies.

A practice worth keeping can answer: what problem does this solve, is that problem present here, and what would we lose by removing it?

Most accumulated process cannot answer those questions. That is the test worth applying — not whether something is standard, but whether it is earning its place in the specific system, with the specific team, against the specific problems that actually exist.