How to use 90-minute coding blocks

…you read “use ninety minutes for deep work” and feel guilty every time your day fragments. Long blocks are not a character test. They are a scheduling luxury. If your calendar cannot host them, the fix is coordination—not shame.

…you have one gnarly task that keeps reloading context. Refactoring with tight tests, debugging intermittent failures, or mapping an unfamiliar subsystem often needs longer uninterrupted time than twenty-five minutes.

The sprint length guide compares options: shorter blocks for startup resistance, fifty-minute defaults for many tasks, longer spans for debugging. This article does not re-derive that matrix. It answers: given you chose ninety minutes, what do you actually do minute by minute?

Think of sprint length as choosing a gear ratio; think of this guide as driving the hill without burning the clutch. You still need the parent article when you are unsure whether ninety is the right gear at all.

Ninety minutes fits work with high reload cost: re-entering a mental model, chasing a subtle bug, or making coherent design decisions that spoil if you stop every twenty minutes.

It also fits when setup cost is front-loaded: spinning local environments, running long test suites, or building a minimal reproduction. If you quit at minute thirty, you pay setup again tomorrow.

Use ninety minutes when you can plausibly finish a meaningful checkpoint—not “the whole project,” but a reviewable unit: a green test, a written design note, a narrowed root cause.

Avoid long blocks when the task is unclear. If you do not know the next action, ninety minutes becomes rumination with a timer. Write a two-sentence plan first—or use a shorter block to discover scope.

Avoid them on high-interrupt days unless your role truly allows ignoring chat. A ninety-minute block that is punctured every ten minutes trains learned helplessness. Shorter blocks with explicit availability windows often ship more.

Avoid them when fatigue is high. Sleep debt turns long blocks into slow motion. Sometimes a focused forty minutes beats a heroic ninety on paper.

Put the block on the calendar if your team respects it. Add a chat status. Close the door. Negotiate coverage if on-call. These sound obvious because calendar failure is the real reason long blocks die—not lack of Pomodoro apps.

If you cannot get ninety contiguous minutes, do not pretend. Stack two forty-five minute blocks with a hard boundary between them, or redesign the work into smaller reviewable slices. Forcing ninety in a broken calendar is how people learn to hate focus techniques.

A simple internal shape: 0–10 minutes warm-up and environment lock, 10–70 minutes core progress, 70–85 minutes consolidation, 85–90 minutes exit note. Adjust numbers if your energy curve differs—the point is intentionality, not precision cosplay.

The core should have one primary thread. If you “just quickly” check email at minute forty, you pay reload tax. Treat mid-block context switches as expensive unless the building is on fire.

First ten minutes are where blocks die. Remove decisions: branch checked out, tests running, ticket open, editor full screen. Start audio policy before typing if audio is part of your stack—see how to use music without getting distracted.

Write the smallest executable next step in one line. If you cannot, you are not ready for a ninety-minute commitment—you are ready for exploration, which should be timeboxed smaller.

Around the middle, attention drifts. The productive response is usually narrower scope, not a social media “micro-break” that becomes thirty minutes. Stand, water, thirty seconds of eyes off screen—then return to the same thread.

If you are stuck, switch mode within the task: read tests, write a failing test, or explain the system aloud in notes. Avoid switching tasks entirely unless you have truly hit a dead end—task switches are expensive in long blocks.

Reserve the last minutes for a checkpoint: commit, push draft, or write a “next session starts here” note. Long blocks fail socially when the next you cannot pick up the thread. Breadcrumbs beat bravado.

If you did not finish, capture honestly what blocked you—ambiguous requirements, tool latency, fear. That log turns the next block into a plan instead of a repeat slog.

After ninety minutes of real focus, take a real break—movement, food, daylight—not another screen. Chat and email are not recovery; they are new work.

If you stack multiple long blocks in a day, watch for diminishing returns. Two deep blocks with recovery between often beats four shallow “deep work” performances.

Confusing timer length with depth. Ninety distracted minutes lose to forty-five focused ones.

Skipping the end note. The expensive part of software is re-entry. Pay the cheap tax of documentation.

Using long blocks to avoid planning. If every block is “just figure it out,” you are funding thrash with heroics.

You can run ninety minutes as one continuous timer or as a labeled block in whatever system you trust. The important part is that the timer reflects a pre-declared intention—not that it matches a blog post’s favorite number.

Nedio lets you set a long sprint and pair it with low-surprise instrumental audio so the “start coding” ritual stays thin. If you already have audio solved and only need a clock, a minimal timer may suffice—see Pomofocus vs Nedio for the bundling tradeoff.

Avoid stacking three competing rituals: calendar block, timer app, music player, and a stats dashboard each demanding attention. Long blocks fail when the scaffolding weighs more than the work.

Remote work trades office noise for chat noise. A ninety-minute block may require explicit team agreements: quiet hours, async review windows, or rotating coverage. If you are primary on-call, long blocks may be structurally dishonest—schedule them around rotation reality.

In offices, headphones plus calendar blocks can still fail when managers treat focus time as optional. Advocacy matters: show what shipped from protected blocks versus fragmented days. Data beats manifestos.

Before you schedule a ninety-minute block, answer:

• What is the narrow outcome for this session?
• What is the first physical action in the editor?
• What interruptions are likely—and how will you handle them?
• What note will the next session need to start fast?

If you cannot answer the first two, shorten the block until you can. Clarity scales better than duration.