Reviewing a change as an engineering activity: setting review depth from the change's risk rather than its size, looking in the order that finds the expensive defects first, refusing to spend human attention on what a formatter or linter should own, writing a finding that can be acted on, separating blocking objections from preferences, and receiving review without either capitulating or defending. Use when reviewing a pull request or a diff, when a review has become a list of style comments, when reviews are slow or rubber-stamped, when a reviewer and an author are deadlocked, when a defect reached production through an approved change, or when deciding what a review mus…
