Surviving Code Reviews
summary
Practical checklist for pull requests: include only the right files, link a single issue, and keep changes small (one example was a 37,000‑line refactor that got closed). Run automated checks: tests, coding‑standards and syntax hooks; use git diff master..HEAD to see just the branch changes and test mergeability with --no-commit. Write tests for failure cases, give clear steps and acceptance criteria, and use a sane commit message format with a short headline and fuller description.
AI-written summary · about
chapters (27)
- 0:00maintainer and team lead
- 1:51unsolicited advice
- 2:133 ingredients
- 3:02perspective
- 4:22ticket(s)?
- 8:19tools
- 11:14exotic code, no comments
- 14:01can you break your code?
- 15:50user is an idiot
- 16:55tests
- 18:30coding standards
- 18:58syntax check
- 24:04accurate
- 25:52sane format
- 28:04apologies
- 33:11description
- 35:40code review
- 35:50review" vs "merge
- 37:36peer review vs gatekeepers
- 38:23key skills
- 39:09documentation
- 39:21database patch
- 39:58template
- 40:34automated build
- 41:17too much feedback
- 41:45sandwich technique
- 42:14harsh feedback
related talks
39mEffective Code Review
21mContinuous Improvements of The Code Review Process
28mPull Requests: Merging good practices into your project
21mA Guide to Perfecting Pull Requests
38mPull Requests and Reviews for Good
47mCode review beyond code style
17mThe Perfect Code Review
41mCracking the Code Review from Guesswork to Automated Guidance