Looks GREAT To Me: Getting Past Bare Minimum Code Reviews
summary
The talk argues concrete fixes: automate linting, formatting, static analysis and unit tests so reviews skip nitpicks; keep PRs small (aim for under 500 lines and fewer than 20 files), review in focused 25–45 minute bursts, and refuse oversized PRs. Use PR templates, code-owners auto-assignment, informational reviewers, and the Triple R pattern (Request, Rationale, Result) for precise comments. It ties these practices to DORA metrics (deployment frequency, lead time ≈ day–week, time-to-restore <1 day) and warns against cutting reviews to game scores.
AI-written summary · about
chapters (10)
- 0:00Code review introduction
- 2:18Pitfalls in code reviews
- 7:17Reviewer mistakes to avoid
- 12:22Fixing review comments
- 24:05PR submission best practices
- 29:49Beyond bare minimum reviews
- 35:54DORA metrics and reviews
- 39:06Closing thoughts
- 39:54Q&A: Large features
- 43:07Q&A: Team size impact
related talks
32mLooks GREAT To Me: Getting Past Bare Minimum Code Reviews
44mCracking the Code Review
23mDrama-Free Code Review!
18mHow To Review Someone's Code While Not Being A Jerk!
01h 05mGetting Good (or Better) at Code Reviews
01h 01mBetter Code Reviews FTW!
59mCode Reviews - Why, what and how
45mCracking the Code Review