The short answer
Deep work for developers is sustained attention on cognitively demanding engineering—implementation, debugging, design—long enough to produce a meaningful checkpoint (tests, PR, narrowed bug), usually inside a calendar-defended block. It is not maximal hours; it is maximal signal per hour when the task deserves uninterrupted reasoning.
One caution up front: the research below supports the cost of interruptions and the value of a restart note better than it supports any particular block length. Treat the length of your block as a hypothesis about your own work.
Who this is for
Individual contributors who ship through long reasoning chains, tech leads who still code, and anyone who ends weeks feeling busy without visible artifacts. If your pain is purely meeting overload, start with the calculator below and the research on context switching cost—depth cannot outrun impossible calendar math.
What deep work is (for developers)
The term comes from Cal Newport's Deep Work (2016): uninterrupted focus on cognitively demanding work. For software, add specificity: you are holding a fragile graph of state—invariants, hypotheses, next edits—and protecting it long enough to move the system measurably. Depth ends with a checkpoint you could show a teammate: a failing test that reproduces the bug, a design note that resolves an ambiguity, a PR that tells one coherent story.
Shallow work is still real work: email, planning, reviews, chat triage. The failure mode is letting shallow work occupy the center of the day without intent, so depth never gets a contiguous runway. When you are in a maker block, the default answer to new inbound is “after this checkpoint.”
Why it breaks at work
Depth breaks for predictable reasons: high meeting load, reactive on-call, unclear priorities, too many tickets “in progress,” slow CI, giant PRs, and tools that reward visible responsiveness over finished work. Personal habits help at the margin; system design dominates the ceiling. In a simulated office task, people interrupted by a “supervisor” compensated by working faster, and reported more stress, frustration and effort (Mark et al., 2008).
Voluntary fragmentation matters too: tab hoarding, mid-debug Slack checks, and “just checking” email. Laboratory work on attention residue found that an unfinished earlier task is linked to worse performance on the next one (Leroy, 2009). Honest diagnosis separates moralizing from leverage—sometimes the fix is calendar design; sometimes it is a five-minute start ritual; often it is both.
Ambiguous goals break depth quietly: you sit in the chair for an hour but never commit to a single hypothesis because the ticket said “improve performance” without a target metric. Depth requires a falsifiable next step—reproduce, profile, patch, verify—so your attention can close loops instead of orbiting possibilities.
Tool sprawl is another thief. Two timers, three music players, and a dashboard you never open create micro-decisions before the editor ever wins. Consolidate surfaces when the failure mode is activation energy, not missing features.
What the research supports—and what it does not
Most claims about deep work lean on a handful of studies. Only some of them involve programmers, and none tests protected blocks as an intervention on shipped software. Here is each source, what it shows, and what it does not. Summaries follow the authors' abstracts; we did not re-run any study.
Leroy (2009)
Indirect: lab, non-programming- Design
- Laboratory experiments: a task was interrupted, then people moved to a different one.
- Shows
- Unfinished earlier work is linked to worse performance on the next task.
- Does not show
- That this happens at the same size in programming, or how long it lasts on a real job.
- Used on this page
- The case for closing a loop (or writing down where you are) before switching.
Mark, Gudith & Klocke (2008)
Indirect: simulated office work- Design
- A simulated office task (writing and answering emails) with interruptions from a “supervisor”.
- Shows
- Interrupted people finished in less time with no difference in quality, and reported more stress, frustration, time pressure and effort.
- Does not show
- Long-run costs, or anything about engineering output.
- Used on this page
- Why “I just work faster after interruptions” is not free.
Parnin & Rugaber (2011)
Direct: programmers, observational- Design
- Recorded programming sessions plus a survey of programmers.
- Shows
- Only about 10% of sessions had programming activity resume within a minute of returning; resuming usually takes navigation first.
- Does not show
- The share of the day spent re-orienting. The 10% counts sessions, not time.
- Used on this page
- Treating re-entry as a real cost for developers, and keeping a note about the next step.
Trafton et al. (2003)
Indirect: lab, non-programming- Design
- A laboratory task where some people got a short warning before an interruption (8 seconds) and some did not.
- Shows
- People with a moment to prepare did so, and resumed the task faster. Those without a warning adapted with practice.
- Does not show
- That a written note works the same way for hours-long engineering work.
- Used on this page
- The idea of a breadcrumb: spend a minute on where you are before you leave.
Masicampo & Baumeister (2011)
Indirect: lab, non-programming- Design
- Several laboratory studies of unfinished goals and unrelated follow-up tasks.
- Shows
- Unfinished goals intruded on other tasks; making a specific plan removed that interference. Plans that people meant to carry out mattered.
- Does not show
- That a plan beats finishing the work, or that the effect carries over to complex engineering.
- Used on this page
- The restart note: a concrete next action, not a vague intention.
Meyer et al. (2014)
Direct: developers, self-report plus observation- Design
- A survey of 379 professional developers and an observation of 11.
- Shows
- Developers named completing tasks and having few interruptions as the top reasons for a productive day. In the observed group, people switched a lot while still feeling productive.
- Does not show
- That interruptions lower measured output. Perception is not output.
- Used on this page
- Warning against treating every switch as damage; it is why this page asks for a checkpoint, not a ban.
Meyer et al. (2017)
Direct: developers, in situ monitoring- Design
- Monitoring of 20 developers at four companies for about 11 workdays each.
- Shows
- Work is highly fragmented, productivity is personal, and emails, planned meetings and unrelated websites were most often tied to lower perceived productivity.
- Does not show
- Causes, or what happens to shipped work.
- Used on this page
- Starting from your own calendar and your own signals rather than a universal block length.
Newport (2016), Deep Work
Argument, not evidence- Design
- A practitioner book that argues from examples and cited research, not an experiment.
- Shows
- A vocabulary and a strong argument for protecting uninterrupted time.
- Does not show
- Evidence that a given number of deep hours improves software outcomes.
- Used on this page
- The term itself. Everything about developers on this page rests on the studies above.
Our reading. Three claims have reasonable support: interruptions cost more than their duration (lab studies), developers resume slowly (observational), and a specific next-step note helps people pick a task back up (lab studies). The weakest link is the one deep-work advice leans on most—that a protected block of a particular length raises output. The developer studies even show people switching a lot while feeling productive. So this page asks you to define a checkpoint and test your own blocks, not to adopt a number.
Tool: how much hard-thinking time does your calendar leave?
Before changing habits, check the arithmetic. Enter a typical day. The calculator compares the same meetings spread through the day with the same meetings batched into one run, and charges one “getting back in” cost for every gap. You set that cost, because only you know it.
Handled in batches, taken off the top.
Your own estimate after a break. It is not a research constant.
Meetings spread across the day
- Open gaps
- 5 × 60 min
- After getting back in
- 45 min per gap
- Hard-thinking time
- 225 min per day
No single gap reaches your 60-minute minimum, so hard work gets done in pieces or not at all.
Meetings batched into one run
- Open gaps
- 2 × 150 min
- After getting back in
- 135 min per gap
- Hard-thinking time
- 270 min per day
Each gap clears your 60-minute minimum.
A model with equal gaps, not a measurement of your calendar. Real days are lumpier, and the numbers show direction rather than a forecast. Nothing you enter leaves this page.
With the defaults—an 8-hour day, four 30-minute meetings, an hour of chat and email, and 15 minutes to get back in—spread meetings leave five 60-minute gaps. After re-entry each is 45 minutes, so none reaches a 60-minute minimum. Batching the same meetings leaves two 150-minute gaps, and both clear the minimum.
Notice what batching does and does not do. It adds only about 45 minutes of hard-thinking time in this example; its larger effect is block shape, turning five pieces into two usable blocks. If your real numbers show gaps shorter than your re-entry time plus your minimum block, no habit will fix that. The calendar will.
Tool: plan one block
A block needs four things written down before it starts: a goal, a checkpoint you could show someone, a first action, and a rule for interruptions. It also needs a place to write the restart note when you stop. The planner builds that card. It nudges you if the goal names a topic instead of an action, and it works with the five-line note from the stop-and-resume guide.
Block: 90 minutes
Goal: …
Done when: …
First action: …
Interruptions: Chat and email closed until the checkpoint.
Before I stop, write:
Changed:
Checked:
Still unknown:
Next action:
Open first:What you type stays in this page. The link to NEDIO carries only the goal and the checkpoint in its address, and only when you click it, so leave out secrets and private code names.
Here is a filled card for the same debugging task. The example is illustrative, not a recorded session:
Block: 90 minutes
Goal: Reproduce the 403 for an expired guest invite
Done when: A failing test shows the response and the branch that returns it
First action: Open authorizeInvite() and run the invite tests alone
Interruptions: Chat and email closed until the checkpoint.
Before I stop, write:
Changed: Added a failing fixture for an expired guest invite
Checked: The handler returns 403 before the refresh-token branch
Still unknown: Whether expired invites should refresh or fail more specifically
Next action: Read the invite policy and decide the expected response
Open first: The failing test and the policy section in the issueThe top half is written before the block, the bottom half at the end. The checkpoint is a failing test, something a teammate could run. The restart note says what was checked and what is still unknown, so the next session starts from a decision instead of from the whole diff.
When to defend a block
This is a working heuristic, not a research result. Ask three questions about the task:
- Could I resume from a one-line note after a ten-minute interruption? If yes, the task is interruptible. Do not spend a protected window on it. If no, the re-entry cost is high: unfamiliar code, concurrency bugs, migrations, security-sensitive changes, and design decisions that are expensive to reverse.
- Is the output a decision or a mechanical edit? Decisions need the whole model in your head. Lint fixes across dozens of files do not; batch them.
- Is the next step already falsifiable? If you can name a reproduce, profile, patch or verify step, a block will convert attention into progress. If you cannot, spend the first minutes writing the checkpoint instead.
Learning counts too. New languages, frameworks, or domains need contiguous minutes so errors become patterns instead of isolated frustrations; the checkpoint can be exercises or notes rather than a merged PR. And use the calculator as a gate: if your re-entry time is 15 minutes, a 30-minute gap is a place for shallow work.
Where your blocks break
If you change twelve variables at once, you learn nothing. Pick the symptom that sounds like your week and follow one page.
I cannot start the hard thing.
Write a first action you can finish in two minutes and open that file only.
Why developers lose focusI am at the editor but my attention keeps sliding off the code.
Shrink the target to one function or failing test, write the question it should answer, and hide everything else.
How to focus on codeI get pulled out, then lose an hour.
Agree a response window for chat, and leave a restart note when you are pulled away.
Context switching costI stop mid-task and cannot find my place tomorrow.
Write the five-line restart note before you close the laptop.
Stop coding and resume tomorrowI do not know how long a block should be.
Try one length for a week and compare how many blocks reached their checkpoint.
Coding sprint lengthMy AI assistant keeps pulling me into side loops.
Set a stop rule: reproduction, hypothesis, test, then decide.
Escape AI debugging loopsMy calendar has no gaps.
Run the calculator above with your real numbers before you change any habits.
Maker-time calculator
Collaboration without fragmentation
Depth is not antisocial. Pairing, design reviews, and incident response are legitimate modes—but they are different modes. The failure pattern is interleaving them without naming the switch: you try to code while half-attending a call, or you answer Slack between every compile because the team never agreed when sync is expected.
Async defaults with explicit windows for sync reduce thrash: write proposals before meetings, comment on RFCs on deadline, and reserve live time for conflicts that text cannot resolve. When leadership equates responsiveness with commitment, push for a response window instead of vibes. “Non-urgent chat within four business hours” is a negotiable policy; “always available” is a throughput problem that shows up later as missed deadlines.
A starting message you can adapt:
Proposal for how we handle non-urgent messages:
- Non-urgent chat and email: answered within 4 business hours.
- Urgent means a production incident or a teammate who is blocked. Page or call me.
- I keep two maker blocks a week (Tue and Thu, 9:30–11:30) and post the checkpoint when each ends.
- If this does not work after two weeks, we change it.The two-week review clause matters. It frames the change as an experiment the team can evaluate, which is easier to agree to than a rule. Use the calculator output as the evidence you bring to that conversation.
A one-week trial
Pick one high-reload task you have been avoiding—not because it is hardest, but because restarting it hurts. The aim of the week is two data points about your own calendar, not a verdict on deep work.
- Monday: run the calculator with real numbers, fill in a block card, and put a calendar hold where you would never skip a meeting.
- Tuesday: run the first block. Stop at the timer, write the restart note, and record whether the checkpoint landed.
- Wednesday: change one thing only, for example the interruption rule or the length, and note why.
- Thursday: run the second block and start from the restart note, not from the diff.
- Friday: ten minutes: how many blocks reached their checkpoint, what broke the others, and which single change will you keep?
Recovery is part of the same system: back-to-back hero blocks without breaks tend to degrade the afternoon. See the research on focus habits, breaks, and interval design before adding an extra block you cannot sustain.
What we do not know
- Whether protected blocks raise measured engineering output. The studies above do not test it.
- How large attention residue is for programmers on real tasks. Most of the lab evidence is not programming.
- Whether a ninety-minute block beats three thirty-minute ones for you. That is your experiment to run.
- Whether the tools on this page change outcomes. They are structured prompts and arithmetic, and we have not measured their effect on anyone.
One disclosure: NEDIO sells a sprint timer, so we have an interest in you using one. The calculator and the planner work without it, and the advice here does not depend on any product. For the related studies on attention, audio and intervals, see the research section.
Primary sources and references
These peer-reviewed papers are linked through their DOI records or publisher pages. They support the directional claims in this article; none directly measures long, production-grade software development.
- Leroy, S. (2009). "Why is it so hard to do my work? The challenge of attention residue when switching between work tasks." Organizational Behavior and Human Decision Processes, 109(2), 168–181.
DOI: 10.1016/j.obhdp.2009.04.002
The basis for the "reload cost" claim on this page: unfinished prior tasks keep occupying attention and can impair performance right after a switch back into a deep block.
- Mark, G., Gudith, D., & Klocke, U. (2008). "The cost of interrupted work: More speed and stress." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 107–110.
DOI: 10.1145/1357054.1357072
A simulated-office experiment behind the claim that interrupted people work faster and report more stress, frustration and effort — the mechanism behind "why it breaks at work".
- Parnin, C., & Rugaber, S. (2011). "Resumption strategies for interrupted programming tasks." Software Quality Journal, 19, 5–34.
DOI: 10.1007/s11219-010-9104-9
Programmer-specific observational research on how developers resume work after interruptions; the closest source here to everyday engineering work.
- Meyer, A. N., Fritz, T., Murphy, G. C., & Zimmermann, T. (2014). "Software developers' perceptions of productivity." Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, 19–29.
DOI: 10.1145/2635868.2635892
A survey of 379 developers and an observation of 11: what developers say makes a good day, and the contrast with how much they switched while feeling productive.
- Meyer, A. N., Barton, L. E., Murphy, G. C., Zimmermann, T., & Fritz, T. (2017). "The work life of developers: Activities, switches and perceived productivity." IEEE Transactions on Software Engineering, 43(12), 1178–1193.
DOI: 10.1109/TSE.2017.2656886
In-situ monitoring of 20 developers over about 11 workdays each: fragmented work is normal, and what feels productive differs from person to person.
- Trafton, J. G., Altmann, E. M., Brock, D. P., & Mintz, F. E. (2003). "Preparing to resume an interrupted task: Effects of prospective goal encoding and retrospective rehearsal." International Journal of Human-Computer Studies, 58(5), 583–603.
DOI: 10.1016/S1071-5819(03)00023-5
A laboratory experiment behind the idea of a breadcrumb: people who could prepare before an interruption resumed the task faster.
- Masicampo, E. J., & Baumeister, R. F. (2011). "Consider it done! Plan making can eliminate the cognitive effects of unfulfilled goals." Journal of Personality and Social Psychology, 101(4), 667–683.
DOI: 10.1037/a0024192
Laboratory studies behind the restart note: unfinished goals intruded on unrelated tasks, and forming a specific plan removed that interference.
Frequently asked questions
Is deep work the same as working long hours?
No. Deep work is sustained attention on a demanding objective long enough to produce a meaningful unit of progress. Long hours without checkpoints often mean shallow thrash spread across more clock time—not depth.
Does this page cover habits and routines?
It covers the minimum: a block card, a first action, and a restart note. For stopping and resuming see the stop-and-resume guide, and for interval length see the coding sprint length guide.
Is this the same as the coding sprint timer page?
No. The timer page explains how NEDIO implements a sprint-shaped block. This guide stays vendor-light so you can separate the idea from the implementation, and the two tools here work without an account.
Is the maker-time calculator based on research?
No. It is a simple model: equal gaps between meetings, with one re-orientation cost per gap that you set yourself. The structure is arithmetic, and the numbers you enter are estimates. It shows direction, not a forecast.
Does NEDIO measure whether I achieved deep work?
No. NEDIO records the goal, the time, the outcome you mark, and a parked next step. It does not read your code or judge depth. The checkpoint is yours to define and check.
Can junior developers do deep work?
Yes, but the shape differs: learning blocks need shorter loops, more notes, and more questions. Depth is not only shipping features—it includes deliberate practice with feedback.
What if my manager expects instant chat?
Negotiate response SLAs for non-urgent channels, document tradeoffs when load is impossible, and batch shallow work visibly. Culture caps outcomes—personal ritual cannot erase always-on norms alone.
How do meetings interact with deep work?
Meetings are not evil—they are expensive context switches. Batch them, shorten defaults, and defend at least one contiguous maker window on build days when throughput matters.
Where do Pomodoro and sprints fit?
They are scaffolding for believable boundaries: start, focus, end with a checkpoint. Match interval length to task type; the sprint length guide compares options and the limits of the evidence for each.
What about ADHD-shaped attention?
Depth still matters, but the scaffolding may emphasize flexible intervals and fewer simultaneous goals. The evidence for specific audio or interval claims is thin; the focus music guide for ADHD developers covers what it can and cannot say.