How Long Can Developers Actually Code Before Output Drops?

It's 11 PM. The bug has been open for six hours. The fix is now three nested ternaries that work, sort of, on the second try, on Tuesdays. The commit message reads "fix" because anything more honest would be embarrassing.

Most developers know this state. The code still compiles. The tests sometimes pass. But the work has stopped being engineering — it's become a tired person typing characters that look like code.

The question worth asking is when the useful work actually stopped, and how long the useful window was in the first place.

Tired code looks like working code until it doesn't.

The Honest Answer Is Four to Six Hours

Multiple lines of research on knowledge work, deep practice, and cognitive performance converge on a tight range. The amount of time most people can spend on demanding intellectual work — coding, writing, designing, problem-solving — and still produce quality output sits between four and six hours per day.

This isn't four to six hours of sitting at the desk. It's four to six hours of actual concentrated work on hard problems, with breaks in between. The remainder of the workday goes to meetings, email, low-cognitive-load tasks, or rest.

The same number shows up across very different sources:

• Anders Ericsson's research: The deliberate-practice work behind the "10,000 hours" idea found that elite performers across domains rarely exceed 4-5 hours of focused practice per day before quality collapses.
• Code analytics: Studies of large code-host activity consistently show bug-introducing commits clustering in late afternoon and evening sessions, after sustained work.
• Developer self-reports: Industry surveys consistently identify mornings as the most productive window, with a steep drop-off after lunch unless real breaks intervene.

The hour-7-through-hour-12 window many developers think of as "grinding it out" is often a slow accumulation of bugs, missed edge cases, and code that the morning self ends up rewriting anyway.

The Ninety-Minute Ceiling

Inside that four-to-six-hour daily budget, attention itself is bounded. The body runs on a roughly 90-minute ultradian rhythm — first studied by sleep researcher Nathaniel Kleitman, then extended to waking cognitive cycles. Roughly every 90 to 120 minutes, alertness peaks and then dips.

Push past the dip and the output doesn't increase. The same hours fill up with more rework. The brain wasn't designed for unbroken six-hour focus blocks. Pretending otherwise is what produces the 11 PM nested ternary.

In practice, a focus block tends to look like:

• Minutes 0-15: Warm-up. Loading context. Re-reading the previous session's code.
• Minutes 15-75: Peak focus. The actual problem-solving happens here. This is where most useful code gets written.
• Minutes 75-120: Diminishing returns. Decisions feel harder, typos increase, the urge to refresh GitHub or Hacker News spikes.
• Minutes 120+: Deep diminishing returns. The work continues, but the bug-to-fix ratio inverts.

A 5-10 minute break around the 90-minute mark resets the cycle. Skip it, and the next "cycle" runs at maybe 60% of the previous one — and the one after that is worse still.

Why Pushing Through Loses

Every developer has shipped something brilliant at 2 AM. The myth of the all-night coding marathon is real because the moments are real. But the cost of those moments — averaged across a career — usually outweighs the gain.

What actually happens in hour 8-12 of a sustained session:

• Working memory shrinks. A constraint set in hour 2 gets forgotten, and the same logic gets rewritten with a subtle conflict.
• Risk assessment dulls. A // TODO: validate input becomes "ship it, see what breaks."
• Code review gets skipped. Self-review especially — the function has been stared at long enough that everything looks correct.
• Architectural decisions get made. The kind of decisions that become technical debt for a year, made by someone whose decision-making faculty is offline.

The compounding cost is what really hurts. Bugs introduced at hour 9 don't show up until production. By the time they're found, the context that produced them is gone, and the fix takes triple the original time.

Output isn't measured in hours typed. It's measured in clean commits that don't have to be reverted next week.

What Sustainable Indie Developers Actually Do

Indie developers who hold quality output over years tend to share a specific pattern. It looks roughly like:

• Two focused work blocks per day: A 90-minute morning block on the hardest problem, a 90-minute afternoon block on the second-hardest. That's the day's real work.
• Lower-stakes tasks fill the rest: Code review, refactoring boring boilerplate, writing docs, planning the next sprint. These can stretch longer because the cognitive load is lower.
• A hard stop, usually around 6-8 hours total: Anything past that gets postponed to tomorrow, when morning-self can do it in 30 minutes instead of two hours.
• Breaks aren't optional: Every 90-120 minutes, away from the screen, doing something that isn't more screens.

This is roughly the pattern Cal Newport documents in Deep Work, what Ericsson found in his deliberate-practice research, and what most successful solo developers describe when asked how they avoid burning out.

The Hard Part Isn't Knowing — It's Stopping

Most developers who've been at it more than a few years already know this. The science isn't the problem. The problem is that "just one more thing" at the 90-minute mark turns into another two hours every single time.

That's where willpower fails reliably. Nobody has the discipline to walk away mid-flow on day 247 of a project. The brain rewards the dopamine hit of pattern-matching the next line of code far more than it rewards the abstract benefit of stretching.

A reminder app helps make the moment automatic instead of negotiable. Limited Session sits in the Mac menu bar with a configurable interval — set to 90 minutes for indie-dev sessions, the full screen takes over with a break overlay at the 90-minute mark. Not a dismissable notification. An actual interruption.

The full-screen interruption is the point. A toast notification gets ignored. A cover-the-screen reminder doesn't.

After two weeks of this rhythm, the 11 PM nested ternary stops happening — not because of more discipline, but because the day is structured to not need any.

The Counterintuitive Win

Developers who switch from "code 10 hours, ship whatever" to "code 4-5 focused hours, then stop" often report shipping more over a month, not less.

The reason is just math. Five hours of clean code beats ten hours of three-hours-of-clean-code-plus-seven-hours-of-bugs-to-fix-tomorrow. The total useful output is higher, even though the time at the keyboard is lower.

The counterintuitive part is just believing it until two paychecks of evidence stack up.

A Reasonable Experiment

For anyone curious to test the rhythm, a one-week experiment takes minimal setup beyond installing a break reminder:

• Set a 90-minute timer on every coding session. When it goes off, stop, regardless of what's in flight. Walk away for ten minutes.
• Cap actual coding at six hours. Tracking it for a week is usually a surprise — many "coding" hours turn out to have been browser time.
• Note the time of day when bugs feel hardest to find. That's the cliff. New code shouldn't be written past it.

After a week, commit quality, PR review comments, and revert counts usually tell the story.

The point isn't to work less. It's to stop wasting the second half of the day producing tomorrow's tickets. The keyboard isn't going anywhere. The work isn't going anywhere. The brain that does the work, though — that's the limited resource. Treating it like one is the whole game.