When you switch from writing code to reviewing someone’s PR, your attention doesn’t immediately follow. Part of your mind stays anchored to that implementation detail you were wrestling with, the edge case you were about to test, the refactoring pattern you were considering. It’s the attention residue problem, and it explains why interrupt-driven code review feels exhausting even when individual reviews are quick.

Sophie Leroy’s research shows that thoughts about Task A persist while performing Task B, degrading performance on both and hurting engagement by roughly 24%. For code reviewers, this means each context switch between your work and someone’s PR carries cognitive overhead that compounds throughout the day.

But reviewers face a worse variant. Authors already have context from writing the code. Reviewers build mental models from scratch each time, then discard them when switching away—perpetually rebuilding, never reaching depth. This compounds when you’re already constrained on memory limits, as attention residue leaves almost no capacity for thorough evaluation.

The compensation pattern is revealing. A 2008 study at UC Irvine found that people work faster when interrupted with no immediate quality decline, but stress and frustration increase by roughly 40% after just 20 minutes. People can push through interruptions in the short term, but pay psychologically. For reviewers, this surfaces as either maintaining thoroughness at the cost of mounting stress, or coping through shallower reviews.

The activities that feel like responsiveness create the problem. Checking Slack, monitoring PR notifications, jumping between reviews. We self-inflict contexts switching too often because it feels productive but in reality, we’re actively fragmenting our own attention.

The Compensation Trap Link to heading

This creates an impossible choice for reviewers. Batch your reviews into protected blocks? You maintain focus and do thorough work, but authors wait. Respond immediately to each PR? Authors stay unblocked, but you never achieve the sustained attention needed for deep evaluation. The industry has settled on a compromise: 24-hour response times (Google’s standard, echoed at Meta, AMD, and Microsoft). This expectation acknowledges that immediate review is unrealistic while preventing multi-day queue buildup from Little’s Law dynamics.

But 24-hour turnaround doesn’t solve the cognitive problem. It just makes the pain tolerable. If you treat code review as interrupt-driven work throughout the day, you’re paying attention residue tax on every switch. If you batch all reviews into a single session, you might blow past the optimal review duration (the SmartBear study from the cognitive load post found effectiveness drops sharply after 60-90 minutes). The solution space is narrow: maybe two scheduled review blocks per day, protecting maker-schedule focus while maintaining same-day turnaround. Morning standup ends, 30-60 minute review session. Mid-afternoon, another block. Predictable for authors, protective for reviewers.

A Surprisingly Simple Fix Link to heading

There’s a mitigation that seems almost too simple. Leroy’s 2018 follow-up study tested “ready-to-resume” plans where before switch-off a task, you write down where you were and what you’ll do when you return. My desk is filled with small sticky notes that do this type of backlog management. In the study, the intervention massively addressed attention residue I think because it gave your brain explicit closure on the interrupted task frees full attention for the interrupting task. This echoes one of the core ideas of the GTD system.

For those switching away from coding / writing, this could be as straightforward writing a one-line note in your current file before switching like “was checking error handling in payment processor, lines 145-203, verify exception propagation paths next.” When you return to your code, that note reconstructs context faster than scrolling through files trying to remember what you were doing. Then, as you’re reviewing code, you’ve given your past work explicit closure instead of letting it generate attention residue. You can also flip this when you’re unable to review code completely with “reviewed until here, will look at error handling and strings next”. Of course IDEs and Tools could make this much simpler, but I can vouch stickies work too.

To wrap this up, the research is unambiguous and unsurprising. Context switching has measurable cognitive costs, and simple interventions can mitigate the damage. Yet most teams treat code review as ambient interrupt-driven work, assuming reviewers have infinite attentional capacity. It’s a natural reaction to the bystander effect but it fails to account for the resulting stress and exhaustion when we push for “fast PRs”.

The deeper question is whether we’re optimizing the wrong thing. Fast feedback matters, but so does thorough review. If interrupt-driven review prevents achieving the focus needed for depth, then optimizing for response speed optimizes for mediocre review. The solutions like scheduling review blocks, ready-to-resume plans, same-day turnaround with protected maker time aren’t revolutionary. Many managers and self-optimizers have naturally landed on similar-ish approaches as well.

The interesting part is how long we’ve tolerated the mismatch, and will continue to in future.