The case for code review is fundamentally economical: it saves the organization money by finding costly issues earlier when they are cheaper to fix without impo

The case for code review is fundamentally economical: it saves the organization money by finding costly issues earlier when they are cheaper to fix without imposing a costlier burden for the review process itself. As generic "knowledge transfer", or even increasing the bus factor, I would disagree. The best knowledge transfer experiences I've had have been dedicated meetings/workgroups dedicated to that purpose, and they tend to encompass larger scopes than a single commit/pull request. I've also seen the difference in devs who contribute to an area having previously only been reviewers of code in that area, vs. actually having a knowledge transfer session with that area's lead beforehand, and in the latter case they are more effective (actually even if they had never reviewed code in that area before, as was the case with interns or new hires). To me knowledge transfer is the nice possible side effect, but not the primary purpose. I'll leave a third opinion from here https://static1.smartbear.co/smartbear/media/pdfs/best-kept-secrets-of-peer-code-review_redirected.pdf#page=16 https://static1.smartbear.co/smartbear/media/pdfs/best-kept-... which lists some direct and indirect benefits: Few developers and software project managers would argue that these are direct benefits of conducting code reviews: • Improved code quality • Fewer defects in code • Improved communication about code content • Education of junior programmers And these indirect benefits are byproducts of code review: • Shorter development/test cycles • Reduced impact on technical support • More customer satisfaction • More maintainable code