Developer burnout is an engineering problem, not a willpower one. Treat velocity as a measurable rate, budget your focus, set WIP limits, and ship fast sustainably.
I hit the wall on a Tuesday, and the strange part was how quiet it was. No breakdown, no drama — I opened my laptop, stared at a merge conflict I'd resolved a hundred times, and simply couldn't make my brain move. We'd shipped a big release the Friday before. I'd promised myself the weekend off and then spent both days "just cleaning up a few things." Not tired-nothing. Broken-nothing. I closed the lid and sat in the dark for an hour.
For years I thought that moment was a character flaw. I wasn't disciplined enough, didn't want it badly enough, hadn't found the right morning routine. That framing is comfortable because it keeps you in control: fix yourself, fix the output. It's also wrong. Developer burnout isn't a willpower deficit. It's a system running past its capacity with no backpressure, no alerting, and no budget — and I only started fixing it when I stopped treating it like a personal failing and started treating it like an outage. This post is the engineering model I now use to ship fast sustainably: velocity as a measurable rate, focus as a finite resource, and constraints in place of raw motivation.
Here's the part that annoys me most in hindsight: the crash was predictable. Not in some vague "you should have known better" way. It was in the data, if I'd bothered to look.
For the six weeks before that Tuesday, my working days had crept from around 9 hours to 13. My commits had gotten later at night — the git log doesn't lie, and mine showed a steady drift toward 1am pushes. My "real work" (features, architecture, hard problems) had quietly shrunk while my reactive work (Slack, review, firefighting) ate the calendar. Sleep dropped. I stopped exercising "just until the release." Every one of those was a leading indicator. Together they were a countdown.
The lie I'd internalized was that burnout arrives suddenly. It doesn't. It's the last event in a chain of small, measurable regressions — exactly like a production incident. Latency creeps up for a week before the pager goes off. Nobody sane says "the outage was a willpower problem." They pull the graphs. So I started pulling my graphs.
If you take one idea from this post, take that mindset shift: your capacity is a system with observable telemetry, and burnout is what happens when you run it with no monitoring. Everything below is just applying ordinary reliability engineering — capacity planning, alerting, post-mortems, load-shedding — to the one production service you can never redeploy from scratch, which is you.
The first thing that had to change was treating "shipping fast" as a mood. Velocity is a rate. Rates have units. And the unit that matters is not hours worked — it's useful output per unit of energy over a sustained window.
Two engineers who each write the same feature in a week did not have the same velocity if one did it in 40 focused hours and the other in 70 grinding ones. The second person borrowed from next week to pay for this one. That's a loan, and the interest is brutal.
I now think about three different numbers and refuse to conflate them:
The trap is optimizing for peak and calling it ambition. Peak velocity that triggers a two-week recovery crater has a lower average than a boring steady pace. On a recent 0-to-1 build at Shpper, I measured this crudely for a quarter — story points is a flawed proxy, but directionally: my "sprint hard, crash, recover" months averaged meaningfully less shipped than the months I paced. The heroics felt faster. The math said otherwise.
There's a queueing-theory intuition underneath this that every backend engineer already knows in another context. Push a server toward 100% utilization and latency doesn't rise linearly — it goes vertical, because there's no slack to absorb variance. People are the same. The closer you run to your true ceiling, the more a single unplanned incident (a production fire, a sick kid, a bad night's sleep) tips the whole week into overtime. Slack in the schedule isn't laziness; it's the buffer that keeps your effective throughput high.
Speed you can't repeat next week isn't speed. It's a withdrawal.
In backend work you don't get infinite database connections, so you set a pool size and you protect it. Focus is the same — a finite resource with a hard cap per day — and I'd been running mine with no pool limit, wondering why it kept exhausting.
So I gave myself a budget. Not a time budget — an energy budget. Concretely, I model my day as having roughly four deep-focus blocks in it, and no more. Deep focus is the expensive currency: architecture, debugging the gnarly race condition, designing a data model I'll live with for two years. Everything else — reviews, standups, Slack, most meetings — runs on cheap currency and I stop pretending it's free.
The budget looks something like this:
# My daily energy budget — a real config, not a metaphorcapacity: deep_focus_blocks: 4 # ~90 min each. Hard cap. Non-negotiable. shallow_hours: 3 # reviews, comms, glue work reserve: 1 # buffer for the thing that catches firerules: - deep_focus_before_slack # spend the expensive currency first - one_context_switch_max # switching taxes the same budget - if blocks_spent >= 4: stop_starting_hard_things
Three rules earned their place through pain:
The reframe that made this stick: an empty focus tank isn't laziness any more than an empty connection pool is the database being lazy. It's capacity. You provision around it or you get errors.
Why 90 minutes and not "as long as I can grind"? Because deep work has a warm-up cost. It takes a real chunk of a block just to load the full problem into working memory — the schema, the call graph, the three edge cases you're juggling. If you fragment the block, you pay that load cost repeatedly and never reach the part where the hard insight actually happens. Protecting the block is really protecting the tail of the block, which is where the value lives. That's also why a "quick 5-minute Slack reply" mid-block is never 5 minutes — it evicts the context you spent 30 minutes loading.
Reliability engineering has a rule I love: alert on the leading indicator, not the outage. Don't page when the site is down; page when the error rate starts climbing, while you still have room to act.
I'd been doing the opposite — my only "alert" was the crash itself. Useless. By then the incident already happened. So I built cheap alerts on the metrics that had predicted my Tuesday.
Mine are dumb on purpose, because a monitor you have to think about is a monitor you'll ignore:
None of these are precise. They don't need to be. A good alert doesn't diagnose — it just tells you to look before the thing falls over. The engineering equivalent is a symptom-based alert versus a cause-based one: you don't need to know why error rate is climbing to know you should page someone. Same here. Two of these firing in the same week and I intervene: I don't push harder, I pull back. That inversion — pull back on the warning instead of gritting through — is the entire game.
One anti-pattern worth naming: alert fatigue. If your thresholds fire every week, you'll learn to ignore them, exactly like a team that mutes a noisy PagerDuty. Tune them so that firing genuinely means "look now." I'd rather miss a marginal week than desensitize myself to the signal.
When we have an incident at work, we run a blameless post-mortem. Not "who screwed up" — "what in the system let this happen, and what do we change so it can't recur the same way." I finally applied that to myself, and it's the single most useful habit in this whole post.
After that Tuesday, once I could think again, I wrote an actual post-mortem. Timeline, contributing factors, the fix. Blameless — the point was never that I'm weak, it was that my system had no backpressure.
The template I use now:
## Personal Incident Report**Trigger:** Shipped release, then worked the "recovery" weekend too.**Impact:** ~4 days at near-zero output. Dreaded the laptop for a week.**Timeline:**- Weeks -6 to -1: hours drifting up, exercise dropped, sleep down.- Week 0: shipped Friday, worked Sat+Sun, crashed Tuesday.**Contributing factors (blameless):**- No recovery block scheduled after a big ship.- No alert on the rising-hours trend.- Treated "rest" as the thing that happens after work is done — so it never did.**What I'm changing:**- Mandatory light week after every major release. Scheduled, not earned.- Weekly review of my leading indicators.- Rest is a scheduled block, not a leftover.
The most important line in any real post-mortem is the last section: the action items have to change the system, not the person. "Try harder next time" is not a fix — it's the same config with a stern note attached. "Auto-schedule a light week after every release" is a fix, because it holds even when future-me is tired and unwise. When you write yours, be suspicious of any action item that depends on you being more disciplined; those are the ones that quietly never happen.
Writing it down matters more than it sounds. A crash you don't examine is a crash you'll repeat with different details. A crash you post-mortem becomes a fix in the system. The goal isn't to never hit a limit — it's to make each limit teach you where the missing guardrail was.
Most productivity advice is a motivational poster with a to-do app attached. "Work smarter, not harder." "Just prioritize." "Protect your energy." All true, all useless, because they're aspirations, not mechanisms. They ask your willpower to hold a line every single day, and willpower is exactly the resource that's depleted when you're heading toward burnout. Advice that only works when you're fresh is advice that abandons you when you need it.
Constraints work because they don't depend on you being strong in the moment. A constraint is a decision you make once, when you're clear-headed, that removes the choice later when you're not. It's the difference between hoping you'll rate-limit yourself and actually deploying the rate limiter.
The difference in practice:
| "Work smarter" (aspiration) | Constraint (mechanism) |
|---|---|
| "I'll try to log off earlier" | Laptop charger lives in another room; hard to work past a point |
| "I should protect deep work" | Calendar has deep blocks pre-booked; meetings physically can't land there |
| "I'll rest more after releases" | Light week is auto-scheduled in the sprint plan, no approval needed |
| "I'll say no to more things" | A hard WIP limit: three active threads max, a new yes needs a no |
Every row on the right is boring and slightly rigid. That's the feature. Good reliability isn't heroic on-call engineers — it's rate limits, circuit breakers, and autoscaling that hold the line without a human deciding to be disciplined at 2am. Design the same way for yourself. Make the sustainable choice the default and the destructive one require effort, instead of the reverse.
The WIP limit deserves its own section, because it's the one that changed the most for me. Work-in-progress limits are load-shedding. A system taking more requests than it can serve doesn't get faster by accepting all of them — it falls over, and worse, it fails everything slowly instead of serving most things well. So does a person. Ten half-finished threads means ten things shipping late and none shipping cleanly.
Three active threads, hard cap. A fourth "yes" requires an explicit "no" somewhere. This maps directly to how a healthy queue behaves: bounded, with an explicit rejection path, rather than an unbounded backlog that silently grows until latency is infinite. This one rule alone killed the low-grade panic of carrying ten open loops at once, and — counterintuitively — sped up delivery, because finished work ships and half-finished work just accrues interest.
Zoom out from the day to the week, because that's the real unit of sustainable pace. A single hard day is fine. It's the week with no trough that kills you.
The principle I stole from server design: don't run at 100% utilization. A system pinned at 100% has no headroom for a spike, and the first surge takes it down. You provision for ~70% and keep the rest as buffer. Same for a week. If every hour is booked at max intensity, the first unplanned incident — and there's always one — pushes you into overtime, and overtime is where the tank drains.
My week now looks roughly like this:
Mon Ramp. Plan, one deep block. Not a hero day.Tue Peak. Hardest problem of the week goes here.Wed Peak. Second hard thing.Thu Build + review. Slightly lighter, still shipping.Fri Ship, wrap, shallow work. No new hard threads after 2pm.Sat Off. Actually off.Sun Off. One 20-min look at next week, no more.
The shape matters more than the exact slots. Two genuine peak days, not five. A deliberate ramp and a deliberate wind-down. Real troughs the pace can recover in. When I tried to make all five days peak days, I got roughly three good ones and two garbage ones, plus a weekend I spent recovering — a worse week that felt more productive because it felt busier. Busy and productive are different metrics. Optimize the wrong one and you'll grind yourself down while feeling virtuous about it.
And after a big release, the week after is a recovery week. Deliberately. Scheduled into the plan, not something I take if I feel like I've earned it — because I never feel like I've earned it, which is precisely the bug. Rest that's contingent on feeling deserving is rest that never gets scheduled; the fix is to make it unconditional, like a cooldown timer that fires whether or not you think you need it.
Here's the tension for anyone running a startup, and I feel it as a CTO every week: the company genuinely needs speed. Runway is finite, competitors are real, the window closes. So the pressure to spike — nights, weekends, heroics — is constant and it's not irrational. It comes from a real place.
But the founder's paradox is this: the person who sprints fastest this month is often the reason the team is slowest next quarter. A burned-out lead ships bugs, makes bad architecture calls, becomes a bottleneck nobody wants to escalate to, and eventually just stops — and a founder stopping is not a two-week outage, it's an existential one. Peak velocity that ends in a crater has a lower average, and a startup is a long enough game that only the average matters.
There's a second-order cost most founders miss: you set the pace for everyone below you. If the CTO is pushing 1am commits, the team reads that as the expected pace, and now you've propagated your unsustainable config to every engineer who looks up to you. Modeling a sane pace isn't just self-preservation — it's the difference between a team that compounds for years and one that churns. The tone at the top is a constraint the whole org inherits, for better or worse.
I've had to learn to model my own capacity as company infrastructure. My focus is a production resource the company depends on, and running it at 100% with no monitoring is exactly the negligence I'd never tolerate in our actual systems. I wouldn't deploy a service with no rate limits, no alerts, and no capacity plan and call it "disciplined." Running myself that way isn't discipline either — it's an outage waiting for a date.
The reframe I'd give my younger self: your job isn't to be the hero who burns bright for a quarter. It's to still be shipping, clearly and well, three years from now. That's an engineering problem. Solve it like one.