A thread that went viral this week asked "Why are so many programmers so miserable?" and the responses sounded like a group therapy session. Thousands of developers finally vocalizing their thoughts - things that are left unsaid during standup.
We all know. We just pretend we don't.
The Numbers Don't Lie
In a 2021 Haystack Analytics study, 83% of developers said they feel symptoms of burnout. Eighty percent. It’s not a blip; it’s a baseline.
Between 2023 and mid-2024, over 360,000 tech workers were laid off across major companies. Many of them watched their remaining teammates absorb double the workload with zero acknowledgment that anything changed.
If 80% of pilots reported burnout symptoms, we'd ground every fleet in the country. But developers? Ship the sprint. Close the ticket. Repeat. 🫠
We Optimized for Velocity and Broke the People
Here's my theory: At some point, the industry as a whole started treating engineering as a throughput issue. More tickets closed per sprint meant more value delivered.
So we built entire cultures around velocity metrics. Story points. Cycle time. Lines of code, if you're unlucky enough to work somewhere that still tracks that.
The outcome was...
→ Engineers are treated as interchangeable ticket-closers, not people who solve hard problems.
→ Context-switching across five projects is called "being agile."
→ Saying "I need time to think about this" is interpreted as "I'm blocked."
→ Burnout isn't a bug in this system — it's the expected output.
We stopped asking "is this the right thing to build?" and started asking "how fast can you build it?" Those are very different questions.
The Disposability Problem
What the viral thread made clear was a prevailing sense of disposability. Disposability not just through layoffs, although that is a major factor.
It's more nuanced. It's hearing that you're a "10x engineer" in your performance review, and then being let go over a zoom call with your slack deactivated. It's seeing a company post record profits while they downsize your entire org.
People are smart. They internalize the message: you are a cost center, not a human.
And after that, the leadership is surprised that the "engagement scores" have decreased. Isn't that ironic?
The Standup Lie
Millions of developers provide an update every morning by answering three simple questions - What did you do yesterday? What are you doing today? Any blockers?
Nobody ever says "I'm burning out and I dread opening Jira." Nobody says "I haven't written code I'm proud of in six months." Nobody says "I used to love this and now I'm just surviving."
That's not because those things aren't true. It’s just that the structure doesn’t accommodate it. Standups for the most part are team status meetings in sheep’s clothing. There's no space for honesty when the clock is ticking and the sprint board is watching. 😐
So What Do We Actually Do?
I don't have a five-step framework. I'm suspicious of anyone who does.
I believe it all begins with being truthful — with yourself initially, and then with those around you. If your job is causing you to be unhappy, that's a fact. It's not a sign of weakness.
→ Protect your time like it's production infrastructure.
→ Push back on artificial urgency — not everything is a P0.
→ Find the people at work who'll be real with you and hold onto them.
→ Remember that your identity is not your Jira board.
The situation will not be resolved by the industry leaders. It has never happened before. The motivation is in the wrong direction. But we can stop pretending that chronic misery is just "the grind" and start calling it what it is: a broken system that chews people up. 🔥
The best engineers I know aren't the fastest ones. They're the ones who stuck around long enough to still care.
If 80% of us are burned out, when do we stop treating it as an individual problem, and start treating it as a structural one? I’d genuinely love to hear — what’s one thing that actually helped you, or one thing that finally made you say enough?
Top comments (2)
A useful way to answer this is to separate what is individual coping from what is structural reality, because the confusion between the two is part of the problem.
First, the burnout signal is not imaginary. It consistently shows up in surveys, retention data, and day-to-day behavior in engineering orgs. The core issue is that most modern software teams are optimized around predictability of delivery, not sustainability of cognition. That mismatch is the root tension.
Software engineering is not manufacturing. Work does not decompose cleanly into interchangeable units of throughput. Yet many delivery systems implicitly assume it does. When that assumption is applied at scale—velocity metrics, constant prioritization churn, multi-stream context switching—the system still “works” in terms of output. It just silently offloads the cost onto attention, motivation, and recovery time.
That is why burnout feels structural: it is structurally produced.
At the same time, it is not entirely out of an individual’s control. The most effective interventions I’ve seen are not motivational; they are boundary and design decisions at the work layer:
But none of these fully solve the systemic layer, because the system incentive is still biased toward short-term delivery signals. That is the uncomfortable truth: many organizations are not structurally rewarded for preserving developer sustainability unless it directly affects output or retention metrics.
So to the final question—when do we stop treating it as individual?
The practical answer is: when burnout starts affecting business-critical metrics in a visible and sustained way. That is when organizations historically change. Not because of moral awakening, but because the cost becomes measurable in delivery instability, turnover, and quality degradation.
Until then, individuals and teams operate in a hybrid reality: the system does not reliably protect them, so they have to build local protections inside it.
The most honest framing is this: burnout is not a personal failure, but recovery still requires personal action within constraints that are largely structural.
If you want a single “point of control” that matters most, it is this: reducing sustained context switching. Everything else tends to cascade from that.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.