Context switching in code review is the tax nobody itemizes. Ask engineers why pull requests are so hard to review and they will point at diff size and missing context, and they are right. But the cost that actually shapes a reviewer’s week is the switch itself: the request that lands mid-task, the mental state rebuilt after every detour, the large diff you re-enter for the third time and re-learn from scratch. Review is not expensive because reading code is slow. It is expensive because of what each round of reading evicts.
Review requests are interrupts
An incoming review request has every property of an interrupt: it arrives asynchronously, it carries someone else’s deadline, and it politely asks you to drop what you are doing. Google’s engineering practices guide resolves the tension explicitly. It asks reviewers to respond within one business day at most, because slow reviews stall authors and breed ever larger follow-ups. The same page tells reviewers not to interrupt a focused coding task to do a review; finish what you are doing and pick reviews up at a natural break point. Those two instructions only coexist if review is scheduled work rather than reactive work. The interrupt framing is a choice the team makes, not a property of the request.
Context switching in code review scales with diff size
The re-orientation cost is not constant; it scales with how much state the review requires. A ten line fix can be reviewed cold in a minute. A forty file refactor demands the same slow build-up every time you open it: what the change is for, which files you already covered, which thread you were pulling when you stopped. That is why large pull requests suffer disproportionately from interruptions: every exit throws away expensive state, and every re-entry buys it back at full price. SmartBear’s peer review research points the same direction: effectiveness falls after about an hour of reviewing, and reviewers should take on no more than around 400 lines at a time. A review you cannot finish in one sitting is a review you will pay for at least twice.
Batch into review blocks
The fix is boring and it works: stop treating the queue as a stream and drain it on a schedule. Two or three fixed blocks a day, thirty to sixty minutes each, placed at natural seams like post-standup and post-lunch, absorb the review load of most senior engineers without touching deep work. The seams matter as much as the blocks: a review slot that starts where focus already broke costs nothing extra, while the same slot dropped into the middle of a maker afternoon costs the whole afternoon. Inside a block, a few rules keep the batch honest:
- Order the queue by staleness, oldest request first, so nothing quietly rots.
- Finish or checkpoint each review before opening the next; two half-reviews cost more than one complete one.
- Right-size what you accept per block. One large diff or several small ones, not both.
- Leave the block on time. An unfinished review with good anchors beats an overrun that eats your afternoon.
An SLA you can keep without live interrupts
Teams usually adopt reactive reviewing out of fear of missing the review SLA, but the arithmetic favors blocks. Two blocks a day put the worst case response at roughly half a working day, well inside a one business day target, and the median far lower. What batching needs to stay safe is an escape hatch: an explicit escalation channel for genuinely blocking reviews, used rarely and honored promptly. That converts the SLA from a vague pressure to respond instantly into two clear promises: routine reviews within the next block, escalations at the next break point. Authors get predictability, which they value more than speed; reviewers get whole mornings back.
Keep your place in the diff
Batching shrinks the number of switches; place-keeping shrinks the price of each one. The humble viewed files checkbox is the most underrated review feature on GitHub precisely because it turns re-entry from an archaeology dig into a checklist: everything checked is done, the first unchecked file is where you resume. Pending review comments work the same way; a half-formed note to yourself marks a thread you meant to finish pulling. The last trick is manual: before leaving a block, write one line about where you stopped and what you suspected. (Disclosure: we build Pyor, where a paused review keeps its viewed files and unsent comment drafts for when you come back.)
None of this makes review free. It makes the cost visible and then schedules around it, which is all anyone does with any interrupt. Authors can help from their side too: a clear description, a suggested reading order, and a diff sized for one sitting all lower the state a reviewer has to hold, and therefore the price of every switch. The teams that treat reviewer attention as a budgeted resource ship reviews faster than the teams that treat it as an always-on service, and their reviewers still have the focus left to catch what the review was for in the first place.
Frequently asked questions
How often should reviewers check for new review requests?
Two or three fixed blocks per day is enough for most teams. Google recommends responding within one business day at most, and a morning plus afternoon block beats that comfortably. The exception is a genuinely blocking review someone explicitly escalates; treat those as true interrupts and pick them up at your next natural break point.
Does batching code reviews conflict with a review SLA?
No. Most review SLAs are measured in business hours or days, not minutes. Two daily review blocks give a worst case response of about half a working day, well inside a one business day target. Batching usually improves the SLA in practice, because review stops losing races against meetings and deep work and gets reserved time instead.
What is the fastest way to resume a half finished review?
Leave yourself a trail while reviewing. Mark files as viewed as you finish them, write pending comments even for half-formed thoughts, and end each session by noting the next file you meant to open. Re-entry then costs seconds. Without those anchors, resuming a large diff means re-reading files you already covered.
