Time blocking for software developers

Time blocking means assigning every hour of your working day to a named piece of work before the day starts, instead of holding a to-do list and picking from it whenever you surface. For developers the appeal is obvious: writing code has a warm-up cost that a list-based day never pays back.

Be honest about the size of the effect. The largest review of time management research (Aeon, Faber and Panaccio, 2021, covering 158 studies and roughly 54,000 people) found a moderate correlation with performance, around r = .25, and a stronger link to wellbeing and lower stress. The authors' own summary was that time management "may primarily enhance wellbeing rather than boost performance." So a calendar full of blocks is not going to double your output. What it reliably does is reduce the daily negotiation about what to work on, and that negotiation is where a lot of engineering mornings go.

The mechanism with the best evidence behind it is the implementation intention: specifying the exact cue and the exact first action rather than a general intent. Gollwitzer and Sheeran's 2006 meta-analysis of 94 studies found a medium-to-large effect (d = 0.65) on goal attainment, independent of how motivated people already were. A calendar block is an implementation intention with a time attached, which is why "Tue 9:00, write the retry logic for the payment webhook" behaves so differently from "work on payments this week."

Most time blocking guides suggest 30 or 60 minute blocks. That is fine for admin and wrong for implementation work. Loading a non-trivial part of a codebase into your head takes real time, and the block has to be long enough that the loading cost is a small fraction of it. Ninety minutes is a sensible floor for anything involving unfamiliar code, and two hours is better. Below about 45 minutes you are mostly paying setup costs.

Leroy's 2009 experiments on attention residue explain why splitting a block hurts more than the clock suggests. Attention stays stuck on an unfinished task and degrades performance on the next one, so an hour split between two services is worth noticeably less than an hour on one. Gloria Mark's field research puts the return time after an interruption at 11 to 16 minutes. The widely repeated "23 minutes and 15 seconds" figure appears in none of her published papers; it came from a press interview and spread on its own. Her more interesting finding is that interrupted work often gets finished faster, but with measurably higher stress. Interruptions tax you more than they tax the schedule.

There is also a ceiling. Ericsson's studies of elite performers found that even people whose entire job is focused practice rarely sustain more than about four hours a day of it, split into blocks with real rest between. Two 90-minute deep blocks plus a shorter one is a full day of hard engineering. If your calendar shows six hours of planned deep work, it is fiction, and the fiction will quietly become an excuse to stop planning at all.

Engineering calendars are not empty canvases. Standup, sprint ceremonies, one-on-ones and incident reviews arrive from other people. Start by laying those down, then look at what shape is left. Usually you find several 40 to 50 minute gaps scattered between meetings, which is the worst possible distribution.

Push meetings toward each other

The single highest-value calendar change most teams can make is to stack meetings back-to-back rather than spread them out. Two meetings three hours apart destroy the whole afternoon. The same two meetings adjacent to each other cost 90 minutes and leave a usable block. When you propose a time, propose one that touches an existing meeting.

Defend one no-meeting half-day

A team-wide no-meeting morning works better than each person individually declining invitations, because the pressure to accept mostly comes from other people's scheduling habits rather than from your own weakness. If the team will not adopt one, book the block yourself with a specific title. "Deep work" invites people to override it. "Payments retry logic" does not, because it reads as committed work.

Price the meetings you can question

Recurring meetings survive because nobody computes what they cost. A weekly hour with eight engineers is a full engineer-day every week. Running the numbers through the meeting cost calculator gives you a concrete figure to put in the conversation, which lands better than an appeal to focus.

Not everything deserves a deep block. Code review, PR comments, Slack threads, ticket grooming and dependency bumps are all interruptible by nature, and they are the natural filling for the fragments between meetings. Put two review windows on the calendar, one mid-morning and one late afternoon, and let reviews queue in between. Most teams find their review latency is unchanged, because latency was never driven by how often people checked.

Batching messages has direct experimental support. Kushlev and Dunn (2015) found that limiting email to a few fixed windows lowered stress. Fitz and colleagues (2019) found that batching notifications three times a day improved mood and attention, while hourly batching was actually worse than the control condition, which is a useful warning against half-measures. A 2022 workplace study adds an important caveat: the benefits faded after roughly two weeks without deliberate maintenance. Treat batching as a practice you re-establish, not a setting you flip.

The one exception worth naming is anything with an on-call or production dimension. Alerts are not messages and should not be batched. Which brings up the mechanism that makes the rest of this survivable on a real team.

Individual time blocking fails on teams where anyone might be pinged about a broken build, a customer question or a flaky deploy. The fix is structural, not personal: put one engineer per day or per week on interrupt duty, publicly, and route everything unplanned to that person. They take support questions, triage alerts, handle the urgent reviews and pick up the small fixes. Their calendar has no deep blocks in it, by design, and their week is planned around interruption rather than against it.

This turns a diffuse cost that damages five people's days into a concentrated cost that damages one, and it rotates. It also makes the deep blocks credible: when a teammate knows exactly who to ask, they stop defaulting to whoever answers fastest. Give the interrupt engineer explicit permission to ship nothing substantial that week, or the rotation quietly becomes a punishment nobody volunteers for.

The most common failure mode of developer time blocking is not distraction. It is that the blocks were too small for the work, so every day ends behind and the calendar starts reading as a list of things you failed to do. Buehler, Griffin and Ross (1994) documented the underlying bias: people systematically underestimate how long their own tasks will take, while observers predicting the same people show no such bias. You are the worst available estimator of your own work.

The countermeasure with the best track record is reference class forecasting. Instead of imagining how this migration will go, look up how long the last three comparable migrations actually took and use that number. Buehler also found that explicitly linking past experience to the current plan reduces the bias, so the act of pulling up the old tickets is doing real work. Kruger and Evans (2004) showed that unpacking a task into its parts raises estimates toward reality, which is why writing the four subtasks before booking the block is worth the five minutes.

Tracking this is easier if the estimate lives with the task. The task manager stores a focus-session estimate per task, so after a few weeks you have your own reference class instead of a general sense that things take longer than expected. There is more on estimation in how to estimate tasks.

Spend the last minute of every block writing down where you stopped and what the next action is. Leroy and Glomb (2018) validated exactly this as a "ready to resume" plan and found the one-minute note measurably protected performance on the following task. Masicampo and Baumeister (2011) showed the related effect from the other direction: unfinished tasks intrude on unrelated thinking, and making a specific plan removes the interference. The note is not documentation. It is what lets you stop thinking about the work while you are in the meeting that follows.

A failing test with a descriptive name works well as the note for code. So does a two-line comment at the cursor. Whatever form it takes, write it before you close the laptop, not after the meeting when the context is gone.

A week that holds up

Monday morning: plan the week and size the blocks against last week's actuals. Tuesday and Thursday mornings: 90-minute deep blocks, no meetings, one task each. Meetings stacked into Tuesday and Thursday afternoons. Two 30-minute review windows a day. Wednesday reserved for interrupt duty if the rotation lands on you. Friday afternoon: the weekly review, which is where next week's blocks come from.