The Focus Leak | Article 7: The Review Stall

Engineers are hired to ship code, but they are often caught in “Human Deadlocks.” While the “Discovery Gap” (Article 6) deals with finding data, the Review Stall deals with the decay of logic while waiting for human approval.

The Problem: Human Deadlocks

In multi-threaded programming, a “Deadlock” occurs when two processes are waiting for each other to finish, and as a result, neither can move forward. In a team, this happens when a Pull Request (PR) sits in “Review Limbo.”

When code is finished, the Mental Map of that logic is at its peak. As hours and days pass without a review, that map begins to evaporate. This is Context Half-Life.

The Reality: The Cost of the “Wait”

If a PR is reviewed 10 minutes after it is submitted, the fix is instant. If it is reviewed 48 hours later:

• The Re-Load: The engineer must spend 20 minutes re-reading their own code to remember why they made certain choices.
• The Conflict: In those 48 hours, the “Main” branch has moved. Now, a “Merge Conflict” occurs, requiring another high-state logic session to resolve.
• The Leak: While waiting, the engineer started a new task. Now they must juggle two complex mental models at once—which usually leads to a System Crash for both.

The Reality: The longer code sits, the more expensive it becomes to fix. “Code in Review” is depreciating inventory.

The Patch: FIFO and High-Frequency Review

To stop the leak, the priority of the team must be shifted from “Starting New Work” to “Clearing the Pipes.”

1. FIFO (First In, First Out) A “Review-First” culture is established. Reviewing a teammate’s PR is treated as a higher priority than starting a new ticket. This ensures that logic is “locked in” while it is still fresh in everyone’s “Mental RAM.”

2. The Small Batch Rule PRs are kept small. A 50-line PR can be reviewed in a “Cool Down” period (5 mins). A 500-line PR requires a full 20-Minute Warm-Up just for the reviewer to understand it. Small PRs prevent reviewers from procrastinating on the task.

3. The Review “Swarm” Specific times are designated for “Review Swarms” (e.g., right after the morning stand-up). By batching reviews, the team ensures that “Blocking Calls” are resolved quickly so everyone can return to a 4-hour Maker Block with a clear head.

Submit a Bug Report

The “Lead Time” for a PR should be checked. How many hours pass between “Request Review” and “Approved”? If the average is over 4 hours, the Review Stall is forcing your team to pay the 20-Minute Warm-Up tax twice for every single ticket.