Getting the Best Out of Your Code Reviews
summary
Argues that code reviews find bugs and spread knowledge, demonstrates concrete practices: use linus’s law, automate checks with linters, static analysis, CI tests and coverage, and avoid merging without review. Gives a real catch — mistyping npm install --save-dev can add a malicious package — and recommends reviewer rules like two reviewers (context + language) or GitLab-style chain reviewers, plus the tactic to add failing test when spotting a bug. Emphasizes clear PR descriptions, limited reviewers, rotation, and assuming good intent.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:30Who am I
- 1:39Different types of experiences
- 3:17Linus Law
- 7:58Saving Dependencies
- 9:47Happy Accidents
- 10:03Biggest Mistake
- 10:39Too Many Reviewers
- 11:26The Right Number of Reviewers
- 14:04What to Avoid
- 15:22Automation
- 16:30Anticipate Questions
- 17:08Your Code is Ready
- 18:17What is Tactical Code Review
- 20:04The Approach
- 20:51Dos and Donts
- 25:18Be Kind
- 27:34Flip Hats
- 27:54First Reaction
- 28:59Second Reaction
- 29:52Assume Good Intent
related talks
41mCracking the Code Review from Guesswork to Automated Guidance
45mHow to Get More Out of Your Code Reviews.
01h 01mBetter Code Reviews FTW!
40mCode Review - How to Do It Better?
33mCode review for Open Source
18mHow To Review Someone's Code While Not Being A Jerk!
46mCode Review, you said?
21mCode reviewing like a champion