Deep work for developers is a loaded working set
Non-developers imagine deep work as typing for hours. Developers know most of the time is holding context: failing test, hypothesis, three files, breakpoint, uncommitted diff, last command, seed data quirk.
Depth means keeping that set stable long enough to change the system and prove it. Anything that dumps the set without saving state is not a break. It is a restart tax.
What qualifies as a deep block
A block counts when it produces one reviewable artifact:
- Pull request with tests and description
- Repro steps and logs attached to a ticket
- Design doc section with decision recorded
- Performance trace with before/after numbers
Reading Slack is not depth. Reviewing twenty tiny pull requests back-to-back is shallow unless that was the planned outcome.
Size the block to the loop
Match length to your compile-test cycle.
Short loop (unit tests in seconds): 40 to 50 minutes may suffice.
Long loop (integration suite, container rebuild): plan 90 minutes or stack work so machine waits carry admin, not a second feature.
Pomodoro for client work helps pick intervals without worshipping twenty-five minutes.
One branch, one hypothesis
Parallel features on one machine split the working set. Cap active code threads at one unless you are explicitly doing triage.
Park other threads with a branch name, ticket link, and next command in the ticket comment. Not in your head.
Reviews and chat belong on the calendar
Pull request reviews interrupt depth. Batch them into a labeled window or you will pay setup tax twice: once to leave depth, once to return.
Same for "quick questions." They are cheap for the asker and expensive for the person mid-loop (interruptions during debugging).
End blocks like you mean to return
Before standup or lunch:
- Commit or stash with message
- Paste failing test output if still red
- Write next physical action in ticket
- Note env quirks (account, flag, port)
Tomorrow’s you is a teammate. Leave work someone else can continue applies to future you.
Environment matters as much as discipline
Noise, bad chair, monitor glare, and family traffic are not character tests. Fix what you can (protect focus at home), then defend time.
Depth without environment becomes heroics that do not scale past one week.
Measure depth in merges, not hours
Track finished artifacts per week, not hours at IDE. If hours rise and merges flatline, you are leaking context or doing invisible rework.
Use the dashboard to name one primary coding outcome per day. Depth is the block where that primary moved to review or blocked with a precise ask.
Deep work for developers is maintaining a working set until the system changes with evidence. Protect that set like production data.
Tooling choices that protect depth
Local test runners, fast linters on save, and IDE indexing reduce how often you leave the editor to "wait for feedback." Slow tooling pushes you toward chat and email while builds run.
Invest in shortening the loop before you invest in another productivity book.
Keep a personal checklist for new repos: clone, env file, seed command, test command. One note in the ticket saves twenty minutes of rediscovery next month.
When depth is the wrong goal
Triage days, release days, and onboarding weeks are shallow by design. Trying to force a feature block into release day creates double failure: neither tickets nor release get full attention.
Name the day type in the plan: depth day, review day, or coordination day. Mixing types without naming them is how guilt appears.
Pairing and mobbing as depth tools
Structured pairing with a driver keeps one working set shared. Unstructured "can you hop on?" does not.
If your team mobbs, timebox and rotate roles so one person is not always navigator on their own feature.
Standups and depth
If standup is mid-block, park first or schedule standup at block edges. Reporting progress while holding a fragile model often loses the model for a status sentence that could wait thirty minutes.