Ask a developer how much of their day goes to code review and you'll usually hear a number bigger than reality. Ask an instrumented study, and the answer is 1.3%. Both can be true at once, because they're measuring different things, and the gap between them is the actual subject of this post.
This isn't a small discrepancy to shrug off. It's the difference between a team believing review is a minor line item and a team correctly accounting for it as one of the more expensive things engineers do all day, just distributed across categories that don't have review's name attached to them. I write about code review from the build side; XenGrowth's growth operations team covers what it takes to run it.
What the instrumented number actually captures
Meyer, Barton, Murphy, Zimmermann and Fritz's monitoring software, running on the machines of 20 professional developers for 220 work days, logged formal code review at 1.3% of the day, debugger use at 0.4%, and version control at 0.7% — 2.4% combined. That's a small enough number that it's tempting to conclude review just isn't a big deal, time-wise. The researchers themselves undercut that reading: a lot of what a reviewer actually does — reading unfamiliar files, checking a linked ticket, comparing behavior against documentation — happens in a browser, and the monitoring tool logged that as web browsing, a separate 11.4% bucket, not as review.
What the tool logged as 'review' | What review actually involves | Where that shows up in the data instead |
|---|---|---|
Time inside the review tool itself | Reading and understanding an unfamiliar diff | Partly logged as review (1.3%) |
— | Checking the linked ticket or spec for intent | Logged as browsing (11.4%) |
— | Tracing how a changed function is called elsewhere | Logged as coding (21.0%) or browsing |
— | Holding the whole mental model while composing a comment | Not logged as a discrete activity at all |
That last row is the important one. The category system these tools use was built to log activities, and holding a mental model isn't an activity with a start and stop event a monitoring tool can see. It's exactly the kind of cost that disappears from every dashboard while remaining fully present in how the day feels.
Why the diff itself is the hard part
Rubinstein, Meyer and Evans' task-switching research gives a precise reason for why this particular switch is expensive. Their four experiments found switch costs growing with two things: the complexity of the rule governing the new task, and how unfamiliar that task was to the person switching into it. Reviewing a colleague's diff satisfies both conditions at once, almost by design. It's rarely a task you were mid-way through yourself — you're switching cold. And it's rarely a domain you hold in working memory the way the author does, since they've been living inside that change for however long it took to write. The XenGrowth resource library approaches this from the the operations side of this side.
A diff is an artifact of a decision process, not the process itself. It shows the lines that changed. It doesn't show the three approaches the author tried and discarded, the constraint from an unrelated part of the system that shaped the final shape of the change, or the assumption baked into a variable name that made perfect sense to write and now needs to be reverse-engineered to check.
The author spent an afternoon building a mental model and left you a diff. Reviewing it well means rebuilding enough of that model to judge the parts you can't see, from an artifact that only shows the parts you can.
This is worth sizing against a large PR specifically, because the cost doesn't scale linearly with the number of changed lines the way a naive time estimate assumes. Each additional unfamiliar file inside the same diff is close to another cold switch, not a continuation of the one before it, if the files touch genuinely different parts of the system.
Review scenario | Approximate switch cost per Rubinstein et al.'s logic | Why |
|---|---|---|
A one-file diff in code you maintain daily | Low | High familiarity, low rule complexity — close to the cheapest case the research describes |
A one-file diff in an unfamiliar service | Moderate | Low familiarity even though the change itself may be simple |
A ten-file diff spanning several unrelated modules | High, and compounding | Each module switch resets familiarity, closer to ten cold switches than one long one |
A small diff with a large, non-obvious blast radius | High despite its size | Complexity here isn't about lines changed, it's about how much of the system the reviewer has to hold in mind to judge it safely |
That table is also a quiet argument for keeping pull requests small and single-purpose, for a reason distinct from the usual ones. It's not just that a smaller diff is faster to read. It's that a diff confined to one familiar area of the system keeps the reviewer inside a single switch-cost regime instead of forcing repeated cold switches across a sitting, which the task-switching research says is where the expense compounds fastest. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
Why review done 'in the gaps' feels even worse
There's a common pattern worth naming directly: review squeezed between other tasks — a favor done while waiting for a build, or knocked out at the end of a coding session before switching off — tends to feel worse and catch less than review given its own clean slot. Leroy's attention residue research offers a plausible mechanism, even though it wasn't run on code review specifically: performance on a task suffers when it follows something left unfinished, especially under time pressure. Squeezing review into a gap next to an open task is close to a textbook setup for exactly that condition — the reviewer isn't just switching into an unfamiliar diff, they're doing it with part of their attention still on whatever they hadn't finished a moment before.
Why senior reviewers don't obviously find this easier
It's tempting to assume seniority solves this problem — a reviewer who's seen more code patterns should reconstruct missing context faster. That's true up to a point, and it's also incomplete, because seniority tends to widen the range of systems a reviewer is asked to look at rather than narrowing it. A junior engineer often reviews within one service they already know well. A senior engineer, or a tech lead, is frequently the one pulled in specifically because a change touches something unfamiliar to the primary team — which is exactly the condition Rubinstein, Meyer and Evans found most expensive, applied disproportionately to the people whose time is already most contested. Experience helps with the mechanics of reading code faster. It does little to reduce the switch cost of a genuinely unfamiliar domain, because familiarity is domain-specific, not a general skill that transfers wholesale.
This has a practical consequence for how review assignments get made. Routing every ambiguous or high-risk diff to the same one or two senior people, on the theory that they'll handle unfamiliarity better, concentrates exactly the kind of expensive cold-switch review Rubinstein's research describes onto a small number of people, over and over, without any recovery period between instances. Spreading unfamiliar review across more people, even if each individual review takes slightly longer per person the first few times, distributes a real cognitive cost more evenly instead of quietly taxing the same two or three people every week. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
What good review tooling would actually optimize for
Most review tooling optimizes for the artifact — better diff rendering, better inline comments, faster CI feedback. Little of it optimizes for the actual bottleneck this post describes: the missing context between what changed and why. A tool that surfaced the author's discarded approaches, the specific constraint that shaped the final design, or a plain-language note on what the diff assumes about the rest of the system would be addressing the real cost directly, rather than making the artifact itself marginally easier to scroll through. Some of this already exists informally — a good PR description does exactly this — which is itself evidence that the fix isn't a tooling problem so much as a habit problem: authors rarely externalize the reasoning because nothing in the process requires it, and reviewers rarely ask for it because asking feels like it's questioning the work rather than reducing its own cost to review.
What this actually implies for how review gets done
Give review its own protected slot rather than fitting it into leftover minutes. The evidence on attention residue suggests the gap-filling approach is close to the worst-case condition for review quality, not a neutral use of spare time
Ask authors to externalize more of the missing context — a short description of what was tried and discarded costs the author little and saves the reviewer from reconstructing it blind, which is where the real cost sits
Stop measuring review load by time spent in the review tool. The instrumented data itself shows that number is an undercount, and using it to argue review 'isn't that expensive' misreads what the study actually found
Batch review of small, similar changes together rather than interleaving it with unrelated deep work, for the same reason batching helps with any activity that draws on the same limited context-holding capacity
Treat reviewer fatigue late in a large PR as a legitimate signal, not a character flaw. It's consistent with switch-cost research on unfamiliar, complex tasks — the tenth unfamiliar file in one sitting costs more attention than the first, and the research says that's exactly what should happen
None of this makes code review less necessary. It makes the 1.3% figure less useful than it looks, and it explains something that engineers have known experientially for a long time without a clean way to say it: the exhausting part of review was never the typing. It's rebuilding, piece by piece, a mental model somebody else already had and didn't hand you along with the diff. The 1.3% was always measuring the wrong artifact — not because the researchers made an error, but because the thing that actually costs a reviewer their afternoon was never going to show up in a log of which application window happened to be in focus.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's revenue operations work covers the go-to-market side of code review, which this piece deliberately leaves alone.
Four questions on the research behind this post's argument.
