Developer Burnout is not the state of being tired of programming. Developer burnout is the state of being tired of everything around programming — the meetings, the sprints, the stand-ups, the retros, the planning, the estimating, the re-estimating, the explaining why the estimate was wrong, the politics, the performance reviews, the career conversations, the “quick questions,” and the specific exhaustion of caring about quality in an environment that measures velocity.
The developer can still write code. The developer can still fix bugs. The developer can still ship features. The developer can no longer remember why.
This is the distinction that non-developers miss: burnout is not the absence of ability. It is the absence of meaning. The burned-out developer is not incompetent. The burned-out developer is competent, productive, and hollow — a machine that produces code the way a factory produces widgets, efficiently and without joy.
The Progression
Burnout progresses through stages that are visible in retrospect and invisible in the moment:
Stage 1: Passion. The developer cares about the code. The developer cares about quality. The developer stays late not because they have to but because they want to. The pull request has detailed descriptions. The commit messages tell a story. The code review comments are thoughtful. The developer argues about architecture because architecture matters. This stage is often confused with dedication. It is dedication. It is also the fuel that burnout will consume.
Stage 2: Frustration. The developer still cares, but the environment does not. The sprint is too short for the work. The technical debt is acknowledged in the retro and ignored in the planning. The developer’s architectural concerns are noted, thanked, and overridden by the delivery date. The developer works harder — not to compensate, but to maintain the quality that the environment is eroding. This is the stage where 60-hour weeks begin, not because of deadlines, but because the developer needs evenings and weekends to do the work correctly that the sprint only allows to be done quickly.
Stage 3: Cynicism. The developer stops arguing about architecture. Not because the developer stopped caring about architecture, but because arguing produces no change and consumes energy that the developer no longer has. The pull request descriptions get shorter. The commit messages become “fix.” The code review comments decrease from “this will deadlock under load” to “LGTM.” The developer is not lazy. The developer is conserving — rationing the diminishing supply of caring across an expanding surface of demands.
Stage 4: Detachment. The developer writes code. The code works. The developer feels nothing. The sprint ends. The velocity is acceptable. The developer opens the job listings tab, scrolls for ten minutes, closes it, and writes more code. The resignation letter is half-written in a private document. It has been half-written for six months. The developer cannot decide whether to finish it, because finishing it requires caring enough to act, and the defining characteristic of Stage 4 is the absence of caring enough to act.
Stage 5: Exit. The developer either leaves (the healthy outcome) or stays (the unhealthy one). The developer who stays becomes the person in the sprint who does exactly what is asked, no more, no less, for years. The developer who leaves discovers, at the next job, that the passion returns — temporarily — until the cycle restarts.
The 120-Hour Week
The Test Coordinator article documents the extreme case: riclib, assigned to rescue a failing project for the largest bank in Portugal, working 90-120 hours per week for months. The record was 120 hours — in a 168-hour week, that leaves 48 hours for sleep, commuting, and maintaining the illusion of having a life.
His hair — what remains of it — did not leave voluntarily. It was worn away by the friction of hands running across the scalp while reading bug reports.
His wife did the math on the Netherlands offer: 50% more salary but 36 hours a week instead of 90-120. The arithmetic of burnout is simple: no salary compensates for the absence of a life. The arithmetic is simple. The decision, in the middle of a rescue, is not.
The 120-hour week is not sustainable. Everyone knows this. The developer knows this. The manager knows this. The company knows this. The 120-hour week happens anyway, because the project is failing and the alternative to the 120-hour week is the project failing harder, and the developer’s instinct — the rescue instinct, the imposter’s need to prove they belong by being indispensable — overrides the body’s instinct to stop.
The project ships. The developer does not recover. The body heals in weeks. The cynicism takes years. The hair does not return.
The Enterprise Machine
Enterprise software is a burnout factory. This is not a design flaw. This is a design feature.
The enterprise values predictability. The enterprise measures velocity. The enterprise plans in sprints and quarters and fiscal years. The enterprise needs developers to produce at a constant rate, like any other resource — interchangeable, measurable, replaceable.
The developer is not a resource. The developer is a person who cares about craft in an environment that measures throughput. The developer wants to build something good. The enterprise wants to build something on time. When these goals conflict — and they always conflict — the developer either compromises on quality (which produces cynicism) or compensates with extra hours (which produces exhaustion). Both paths lead to burnout. The enterprise does not distinguish between them, because both paths produce acceptable velocity until the developer leaves.
The retro says “improve work-life balance.” The retro has said “improve work-life balance” for twelve consecutive sprints. The action item is copied from the previous retro. The action item is never actioned. The retro continues.
The Solo Developer’s Escape
riclib escaped the burnout machine by leaving it. Not leaving software — leaving the enterprise. The transformation from enterprise consultant to Solo Developer was not a career change. It was a medical decision.
The solo developer does not have sprints. The solo developer does not have velocity metrics. The solo developer does not attend retros about work-life balance. The solo developer works when the work is interesting and stops when it isn’t. The solo developer’s 2 AM coding session is not burnout — it is Hyperfocus, which is voluntary (or at least, voluntarily involuntary), which is different from the 2 AM caused by a deadline that someone else set.
The distinction between burnout’s 2 AM and hyperfocus’s 2 AM is the distinction between obligation and obsession. Both keep the developer awake. One destroys. The other creates. The solo developer’s privilege is the ability to choose which 2 AM they experience.
This privilege is not available to most developers. Most developers work for companies. Most companies have sprints. Most sprints have deadlines. Most deadlines have been set by someone who does not write code. The burnout machine continues.
"The Lizard has never experienced burnout. The Lizard works when there is work. The Lizard rests when there is rest. The Lizard does not understand ‘sustainable pace’ because the Lizard’s pace has always been sustainable. The Lizard considers this obvious. The enterprise considers this impossible."
— The Lizard, who has never attended a retro
Measured Characteristics
- Developers experiencing burnout: estimated 40-60% (at some point in their career)
- Average time from passion to cynicism: 2-4 years (environment-dependent)
- Sprint retros that mention work-life balance: ~80%
- Sprint retros that improve work-life balance: ~5%
- Weekly hours at peak burnout: 60-80 (enterprise), 90-120 (rescue mode)
- Weekly hours that are sustainable: 35-40 (everyone knows this)
- Weekly hours that are expected: 45-55 (nobody says this)
- Commit messages at Stage 1: descriptive, thoughtful, telling a story
- Commit messages at Stage 4: “fix”
- Code review comments at Stage 1: “this will deadlock under load, here’s why…”
- Code review comments at Stage 4: “LGTM”
- Job listing tabs opened per day at Stage 4: 1-3
- Applications submitted: 0 (too burned out to act)
- Resignation letters half-written: 1 (for months)
- Hair lost to bug report friction: varies
- The solo developer escape: available to few, transformative for those
- The Lizard’s pace: sustainable (since 1976)
