> Code review was never about catching bugs. Not primarily, anyway. That's incorrect. Code review originated as a technique specifically to find defects, unde

> Code review was never about catching bugs. Not primarily, anyway. That's incorrect. Code review originated as a technique specifically to find defects, under the name Fagan Inspection. That we've found peripheral benefits is great, but the central justification is defect reduction. > Code is written for humans to read (and modify), and a reviewer's job is to make sure the code can adequately fulfill that purpose. I quite like that formulation, but it doesn't undercut the point that we only seem to be able to cope by having a second (third, fourth) pair of eyeballs inspecting every single line of code after it's been written, rather than working on systems to get it right first time. > false dichotomy It's not, though. There is a real difference. If you find a defect in the code, you've definitely prevented a bug from reaching production today. If you find a style problem in the code, you've maybe prevented next month's work from slowing down. If the project stopped tomorrow, none of the style issues would matter, and the code would continue working just fine.