The Context-Switching Cost of Code Review

I have around five pull requests to check on an average day. That's an estimate. They generally touch areas outside the task I'm working on, so picking one up means learning enough about someone else's work to review it.

Sometimes we're working in the same area. Those reviews are easier to start because I already have some of the context in my head. That happens, but it's the less common case for me.

The awkward part comes after I've left feedback. The author responds or updates the code, and I need to check it again. By then I've gone back to my own work. The response hasn't arrived within a few minutes, while I still remember the reasoning. I have to build that context up again.

Five PRs also doesn't tell you how many times I'll open them.

Batching reviews still leaves unfamiliar code to learn

Putting reviews into a block of time is a reasonable way to protect a coding session. It leaves a harder question: what belongs in that block?

If I put all five unfamiliar PRs next to each other on a calendar, they're still unfamiliar. Each may need a different explanation of the code around it. Batching changes when I leave my own task; it doesn't give me the background for the next person's change.

For someone trying review batching, I'd start with a break already in the day. Google's code review guidance recommends waiting for a natural break in focused coding before responding. It also recommends giving the author an expected review time when a full review has to wait. That's advice about responsiveness, with room to finish the thought you're working through.

At that break, check whether anything needs action before the next one. Ask the author what is blocked and when they need an answer. A change needed for someone else's work this afternoon deserves a different decision from a change whose author can continue until tomorrow. If you cannot review in time, say so while there is still time to find another reviewer.

You can try reviewing related changes together when their dependencies allow it. The exception in my own day is why I'd consider it: working in the same area means I already know some of what I'm looking at. But I wouldn't keep an unrelated change waiting just to assemble a convenient batch. Someone else's afternoon is involved too.

Give the reviewer a place to start

For an unfamiliar area, an author can include a short explanation of the behavior being changed and the reason for it. Link the relevant design decision, and point to where the behavior is exercised. A list of filenames alone leaves the reviewer to infer why those files belong together.

Google's guidance on change descriptions explicitly asks authors to explain why a change is being made, including decisions that aren't apparent in the code. This is useful even for a small diff.

Here's an example of the kind of context I'd ask for, using a hypothetical retry change:

This changes what happens when a retry arrives after the original request has completed. Start with the completed-request check; the test beside it covers that ordering. The timeout behavior is unchanged.

Now the reviewer has a claim to test: a late retry should find the completed request. They can follow that path through the code.

I wouldn't turn this into a separate document for every PR. Put it where the reviewer is already reading, and update it when the scope changes. For code in an area you both know well, it may only take a sentence about the unexpected part.

Leave enough reasoning for the second pass

My re-review problem starts with forgetting what I understood on the first pass. A new commit tells me that something changed. It doesn't bring back the reason I asked for it.

One practice worth trying is to leave the condition you were concerned about in the original review comment. For that hypothetical retry change, a comment could point out that the completed-request record expires. Ask whether a retry arriving after expiry could run the operation a second time. The author's follow-up can then point to the change addressing that condition.

On return, you can check the expiry case. The author might have extended retention, or they might explain that another part of the system rejects retries that late. Either answer needs checking against the code.

Record which revision your feedback applies to. When an update arrives, read the comment and the author's response before inspecting the new code. In the retry example, follow the expiry behavior far enough to see whether an old request can actually run again. A new test is useful evidence, but its setup might skip the very condition you were worried about.

The re-review guide covers when to use an incremental comparison and when changed assumptions require a wider pass.

There is a limit here. Prioritizing interruptions won't make a complex or oversized change easy to understand. Even a careful description can leave you needing a conversation with the author before you can review responsibly.

Deciding whether to reopen it yet

While the author is still addressing feedback, opening the PR again can leave you with nothing to do. Once they answer a question, there may be a reason to return even before another commit arrives. This is where knowing who owns the next move helps with scheduling the next look.

In PR Flow, the review queue separates Needs you from Waiting on others. When the author of a PR you've commented on answers you, that conversation can bring the PR back to Needs you. The review queue page explains those attention states. The queue cannot recover the reasoning I forgot between reviews.

I'm still unsure how much of my day would improve through batching alone. With the reviews I get, so much depends on whether I'm already working in that area. I'd want to try it without letting the unfamiliar PRs become the ones I keep postponing.