Article illustration 1

"People are complicated: they have sides you don't know, their actions are driven by private reasons that are impossible to see from the outside. We only glimpse a tiny fragment of what they have inside and out."
— Sarah, Tear Along the Dotted Line

As AI dramatically increases the volume of code requiring human validation, the efficiency of code reviews has become a critical bottleneck in software delivery. Sergey Tselovalnikov, drawing from thousands of pull requests, argues that despite countless articles on "best practices," truly effective reviews hinge on just two fundamental rules focused squarely on the reviewer's behavior.

The Hidden Cost of Delayed Reviews

Rule #1 isn't about rubber-stamping code—it's about minimizing reviewer response time. The penalty for delay feels minimal to reviewers, but for authors, it's a productivity killer:

  • Context Decay: Within hours, authors start losing the intricate mental model of their change. After a day, significant reloading is needed. A week later? It's essentially starting from scratch.
  • Momentum Loss: Blocked workforces context switches onto other tasks, fracturing focus and slowing overall throughput.

"There is nothing worse than silence," Tselovalnikov warns. A swift response—even if it's questions or initial concerns—keeps the process moving. Senior engineers set the cultural norm here; delayed responses from them cascade into systemic slowdowns.

The Magic Word: "Because"

Rule #2 demands that every review comment includes an explicit 'because' clause. This isn't just politeness—it's a forcing function for clarity and value:

  • Eliminates Nitpicking: If you can't articulate why a change is needed (e.g., "Rename this variable because its current name implies it handles user input, but it actually processes system events"), the comment likely shouldn't exist.
  • Accelerates Resolution: Clear rationale reduces back-and-forth. Authors understand the underlying problem, enabling faster, more accurate fixes.
  • Builds Knowledge: Junior engineers learn design principles and domain context through the 'because,' turning reviews into implicit mentorship.

Why Senior Engineers Hold the Key

Tselovalnikov highlights a dangerous trap: as engineers ascend to senior/staff levels, they review more and code less, often forgetting the acute pain of stalled PRs. When they deprioritize reviews or leave cryptic comments:

  1. They establish a toxic cultural precedent.
  2. Junior engineers mirror this behavior, amplifying delays across the team.
  3. Code review shifts from a collaboration tool to a demoralizing hurdle.

"The only way to battle this is to force yourself to follow these rules," he insists. Consistent adherence from leadership transforms reviews from friction points into genuine accelerators. While acknowledging open-source projects may face different constraints, these rules prove transformative for aligned teams—from startups to enterprise squads—turning the dreaded PR queue into a streamlined conduit for quality.

Source: Two Simple Rules to Fix Code Reviews by Sergey Tselovalnikov