I didn't burn out from working too hard. That's the part nobody warned me about.
I burned out while working a normal amount, on a normal team, with normal hours. There was no dramatic crunch. Just a slow grey fog where code I used to love became a thing I dreaded opening. By the time I admitted it, I was months in.
I climbed out. The causes turned out to be the quiet ones — the ones that never make it into a sprint retro. Here's what they were, and what actually worked.
Developer burnout is rarely about hours. It's about a steady drip of friction, lost control, and meaningless effort that no single day makes visible.
The quiet causes:
What pulled me out wasn't a vacation. It was changing those specific things.
The standard story is that burnout comes from too many hours, and the cure is rest. Take a break, come back fresh.
I took a two-week break. I came back and felt the fog roll in again within days. That's when I realized rest wasn't the fix, because overwork wasn't the cause. I'd been treating a symptom.
Burnout, for me and for most developers I've talked to since, is less about volume and more about quality of effort. You can work forty energizing hours and feel great. You can work twenty draining ones and feel hollow. The hours aren't the variable that matters. Year after year, the Stack Overflow Developer Survey finds that low job satisfaction tracks far more closely with friction and lack of autonomy than with raw workload — which matched my experience exactly.
The deepest drain was building things I couldn't connect to anything that mattered. Ticket, ticket, ticket, with no line of sight to why any of it helped a real human.
Meaningless effort is uniquely exhausting. Your brain is wired to spend energy on things that pay off, and it quietly rebels when the payoff never appears. I wasn't tired from the code. I was tired from not knowing why I was writing it.
Nothing drains a developer faster than effort that disappears into a void. We can do hard work forever. We can't do pointless work for long.
The second killer was never getting a clear runway to think.
A standup, then a Slack ping, then a "quick question," then a meeting, then back to code, then another ping. Each interruption is small. The cost isn't the interruption — it's the twenty minutes of re-loading the problem into your head afterward, over and over, all day.
By 5 p.m. I'd been busy for eight hours and built almost nothing, because I'd never strung together more than twenty uninterrupted minutes. That gap between busy and productive is its own special despair.
The flaky test you re-run three times. The deploy that takes nine minutes. The local setup that breaks weekly. The tool that needs the same manual workaround daily.
Each one is small enough to ignore, so you do. But they compound. Death by a thousand papercuts is real, and the worst part is you adapt to the pain until you can't even see it anymore. You just feel inexplicably worn down.
When I finally listed every small daily friction, the list had nineteen items. Nineteen tiny taxes I paid every day without noticing the bill. The slow build was right at the top — and fixing it turned out to be the same exercise as cutting my build times in half in one afternoon: measure the friction, then kill the biggest source first. None of them was worth complaining about on its own — that's exactly why they survived. A papercut isn't dramatic enough to fix, so it stays, and then it has nineteen friends. The danger of small frictions is that they hide below the threshold of "worth doing something about," and they collect interest in silence until the sum is a genuine drain on your energy that you can't trace to any single source.
The fix wasn't one big change. It was attacking the quiet causes directly:
| Quiet cause | What fixed it |
|---|---|
| Pointless work | Demanding line of sight to impact |
| Context-switching | Calendar-blocked deep work |
| Daily friction | Automating the papercuts |
| Invisible progress | A "done" log |
| Unspoken overload | Saying no out loud |
There's one quiet cause I left for last because it's the one people are most ashamed to say out loud: sometimes you burn out because the work has simply stopped being interesting, and you feel guilty even noticing.
We're told we're lucky to have these jobs, that complaining is ingratitude, that being bored is a character flaw. So when the problems stop being puzzles and start being chores, most developers swallow it and grind harder. That grinding-through-boredom is its own slow poison, and it almost never shows up in a retro because admitting it feels like admitting weakness.
Here's what I had to accept: curiosity is fuel, and you can't run on an empty tank by sheer willpower forever. For a while I'd been solving the same kind of problem over and over. Nothing was new. Nothing stretched me. The work wasn't hard — it was flat, and flat is exhausting in a way that hard isn't. Hard problems are tiring but energizing. Flat ones are draining with nothing to show for the drain.
The fix wasn't to quit. It was to deliberately reintroduce difficulty. I asked for a project in a part of the system I didn't understand. I picked up an unfamiliar tool on purpose. I volunteered for the gnarly problem everyone else avoided. It was uncomfortable and I was bad at it for a few weeks — and that discomfort was the most alive I'd felt at work in months. Boredom, it turns out, isn't a sign you should rest. Sometimes it's a sign you should reach for something harder. The grey fog of "I don't care about this anymore" often lifts not when the work gets easier, but when it finally gets interesting again. Give yourself permission to be bored, and then give yourself permission to do something about it.
If naming the quiet causes resonated, it's the kind of unglamorous, sustainable-career thinking I keep coming back to — worth following along if you're trying to stay in this work for the long haul instead of grinding through it.
Q: How do I know it's burnout and not just a bad week? A bad week passes with rest. Burnout doesn't — you rest, return, and the dread comes back within days. The durability after recovery time is the tell.
Q: I can't control my projects or meetings. Now what? Start with what you can control: protect even one deep-work block, kill your own friction, keep a done log. Small reclaimed control matters more than its size suggests. Then push, gently and specifically, on the rest.
Q: Will switching jobs fix it? Sometimes — if the new place lacks the specific causes draining you. But if you can't name what's draining you, you'll often carry the same patterns to the new desk. Diagnose first.
Q: Is this just about work-life balance? No. I had balance and still burned out. It's about the quality of the work hours themselves — meaning, focus, friction, and visible progress — not the boundary around them.
I burned out without overworking, and I recovered without resting more. That contradiction is the whole lesson.
Developer burnout is mostly a quiet drip of pointless effort, shattered focus, and unnoticed friction — none of which show up in a retro. Fix the drip and the fog lifts, often faster than you'd believe.
If work you used to love has started to feel grey, don't reach for a vacation first. Reach for the list of quiet causes. Which one is draining you — and what's the smallest thing you could change about it this week?
Leaving my job wasn't a leap of faith. It was a spreadsheet. Here's the runway math that turned a terrifying gamble into a boring, calculate…
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!