Deep Work for Developers Who Keep Getting Interrupted

Every deep work guide I have read assumes I control my calendar. I do not. There are standups, code reviews, a support channel, and the colleague whose "quick question" has a 40-minute half-life.

So this is not a guide about becoming a monk. It is the system I run inside a normal, interrupt-driven job. Five parts, all cheap, none of them requiring anyone else's permission.

1. Work in 90-minute blocks, and defend only those

Ninety minutes is long enough to load a hard problem into your head and make a dent in it, short enough that nobody panics about your absence. I book two blocks on most days, three on a good day. Everything else — chat, email, reviews — lives outside the blocks.

During a block: chat goes to do-not-disturb, the phone sits in a drawer, and one task is open. Not one project. One task, written on paper before the block starts.

Two blocks a day sounds low. It adds up to 15 hours a week of actual building, which is more than most interrupted weeks produce.

2. Keep an interruption log

For one week, I wrote down every interruption: time, who, what they wanted, and whether it could have waited. The log was embarrassing for everyone, including me. Patterns showed up fast:

• A third of the "urgent" questions answered themselves within an hour.
• Most of the rest were status checks that a visible task board would have covered.
• I was my own worst interrupter. Half the context switches were me checking chat with no prompt at all.

You cannot fix what you have not counted. One week of logging gives you the evidence to change two or three specific things instead of vaguely "focusing more."

3. Reply async-first

Most messages do not need a live human. They need a written answer within a few hours. So I batch replies into three windows a day and say so in my status: "I answer messages at 10:30, 13:30, and 16:00. For a production fire, call me."

People adapt faster than you fear. The genuinely urgent stuff finds the phone number. The rest arrives in the windows, and a written answer is usually better than a hallway one anyway, because the next person with the same question can be pointed at it.

4. Audit your meetings like you audit dependencies

Once a month, I go through every recurring meeting and ask three questions. Does it need me, or would the notes do? Does it need to be live, or would a written update cover it? Does it need 60 minutes, or did someone just accept the calendar default?

Recurring meetings are subscriptions. They renew silently and charge you weekly. In one audit I dropped two, converted one to a written update, and cut one to 25 minutes. That returned roughly three hours a week, every week, for a one-time 20-minute review.

5. End with a shutdown ritual

The last 10 minutes of the day, same routine:

1. Write down where each open task stands, in the task itself, not in my head.
2. Note the first step for tomorrow's first block.
3. Close every tab and window. All of them.
4. Say the day is done and mean it.

The point is not tidiness. An unfinished task with no written next step keeps chewing on your attention all evening. Ten minutes of notes buys the evening back, and tomorrow's first block starts in two minutes instead of twenty because the next step is already written down.

A sample day

Block 3 is deliberately lighter. Attention late in the day is real but shallower, and scheduling tests and documentation there stops them from eating the morning.

The honest part: 8 focused hours do not exist

The fantasy version of deep work promises a full day of flow. It will not happen, and chasing it makes the real version look like failure. Between meetings, reviews, incidents, and a brain that tires, three to four genuinely focused hours is a strong day for most developers. The two or three blocks above get you there.

The goal was never a silent calendar. It is a week where the hard problems got your best hours instead of whatever attention was left after the interruptions took theirs.