The Cognitive Load of Code Review

Code review is one of the most cognitively demanding activities in software engineering. Yet we rarely discuss the psychological principles that make certain review processes effective while others drain teams and produce superficial feedback.

Working Memory: The Bottleneck

George Miller’s famous paper on working memory capacity identified the “magical number seven, plus or minus two” as the limit of items we can hold in consciousness simultaneously. Modern cognitive science has refined this further, showing that for complex items like code structures, the limit is closer to four chunks.

When reviewing a 500-line pull request, a reviewer must maintain context about:

• The stated purpose of the change
• The existing system architecture
• Edge cases and failure modes
• Code style and conventions
• Performance implications
• Security considerations
• Test coverage adequacy

Each of these dimensions competes for limited cognitive resources. The result? Reviewers resort to pattern matching on superficial issues like formatting while missing deeper architectural concerns.

The Ego Depletion Effect

Roy Baumeister’s research on ego depletion revealed that willpower and decision-making ability are finite resources that deplete throughout the day. Code review requires sustained executive function: making judgment calls, suppressing the impulse to approve quickly, and maintaining critical attention to detail.

A reviewer making their twentieth decision about code correctness shows significantly degraded judgment compared to their first.

This has practical implications. Teams should structure review sessions early in the day, limit review size to preserve decision quality, and recognize that back-to-back reviews lead to rubber-stamping.

Psychological Safety and Critique

Amy Edmondson’s work on psychological safety in teams reveals why some engineering cultures produce thorough reviews while others generate perfunctory approvals. When team members fear negative evaluation, they avoid critical feedback that might be perceived as confrontational.

The most effective teams separate critique of code from critique of people. They establish norms where:

1. Questions are framed as genuine curiosity rather than accusation
2. Authors provide context about constraints and tradeoffs
3. Reviewers acknowledge uncertainty in their own understanding
4. Alternative approaches are discussed without hierarchy

Practical Implications

Understanding these cognitive constraints leads to better engineering practices:

Optimal PR Size: Research suggests 200-400 lines as the sweet spot where reviewers can maintain sufficient context without overwhelming working memory. Beyond this threshold, defect detection rates decline sharply.

Review Timing: Schedule complex reviews during peak cognitive hours. For most engineers, this means late morning after initial focus work but before decision fatigue sets in from meetings and interruptions.

Context Loading: Authors should invest time in clear PR descriptions that prime reviewers with the right mental model. A well-written description reduces the cognitive burden of context switching by 40-60%.

The intersection of psychology and engineering reveals that our tools and processes must account for human cognition, not just computational complexity. When we design review workflows around how minds actually work, we get better code and healthier teams.