Getting Past Bare Minimum Code Reviews
summary
Actionable claims and concrete rules: code reviews work best in 25–45 minute focus bursts, PRs aim for under 500 lines and usually fewer than 20 files, automation (linting, formatting, static analysis, tests) catches low‑value issues early, and authors use draft PRs and PR templates to surface the why. Review comments follow the Triple R pattern: request, rationale, result; labels like need_change / needs_rework keep discussions efficient; code-owners and auto-assigned reviewers reduce bottlenecks.
AI-written summary · about
chapters (7)
- 0:00Better code reviews
- 1:48Code review importance
- 8:05Reviewer mistakes
- 21:53PR author mistakes
- 30:04Improving pull requests
- 37:50Beyond bare minimum
- 45:01Q&A
related talks
44mInspect & Adapt, then What?
58mIntentional Code - Minimalism in a World of Dogmatic Design
32mMerge Strategies at Scale: Developer Happiness Through Better Code-submission Workflows
13mReviewing code review duty, fun or... revenge?
41mBuilding a Culture of Quality
24mRoad to Zero Lint Failures: Tackling Code Quality Challenges at Scale
50mPanel: Beyond The Vibe: Code Quality First
20mPrioritizing Technical Debt as if Time and Money Matters