Engineering Practice
Code review: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of pulling it back is what makes the unit’s operating model stick.
Reconstruct the unit’s spine — review’s purpose, the PR-size lever, the latency story, severity-tagged actionable feedback, author preparation, and how review scales — without looking back at the lessons.
- 01What is the real dividing line between what a human reviewer should catch and what tooling should, and why is it not 'importance'?
- 02Why does a 1,600-line PR get LESS effective review than a 160-line one, and what's the supporting data?
- 03Why is 'review faster' usually the wrong instruction for latency, and what variable should you change instead?
- 04What two things must every review comment make explicit, how do you encode them, and what does unlabeled nitpicking cost?
- 05What did SmartBear find about author preparation, and why does psychological safety matter for review?
- 06How do you scale code review across a growing org, and when do you change the shape of review rather than just speed it up?
If you could reconstruct each answer from memory, you hold the unit’s spine: review exists for the undecidable, so automate the decidable into a blocking gate; PR size is the master variable that sets latency and detection together, and small or stacked PRs move both; latency is dominated by pickup, so shrink service time rather than pressure the clock; feedback works when it states severity and a fix and aims at the code; the author’s own annotation finds defects no reviewer sees; and at scale you route to a team, time-box pickup not completion, balance load, and change the shape — pairing or post-commit on a tested base — measuring outcomes, never activity.