Conducting Humane Code Reviews
summary
Outlines four concrete review goals—catch design flaws, ensure clarity, validate necessity, confirm functionality—and names three recurring failure modes: subjectivity (replace var with const debates), toxic tone (“this implementation is terrible”), and process loopholes (no reviews, buddy approvals, or 50+ file PRs). Recommends a living team working agreement, automated lint/format enforcement like prettier and eslint, GitHub code owners, two approvers minimum, and an option to “declare a code review” for oversized PRs so every change actually gets checked.
AI-written summary · about
chapters (10)
- 0:00Introduction to talk
- 1:04Code review goals explained
- 2:51Top complaints about reviews
- 4:55Consensus and team agreements
- 7:00Subjective vs objective feedback
- 8:05Tone of voice matters
- 9:56Guidelines for kind reviews
- 12:10Process loopholes to avoid
- 15:49Fair review enforcement
- 16:33Q&A session
related talks
40mCode Review - How to Do It Better?
31mMay the Code Review Be with You
47mOpen discussion: Premises and promises of code review
18mHow To Review Someone's Code While Not Being A Jerk!
23mDrama-Free Code Review!
05mAn Effective Code Review
53mCode Review Beyond Code Style
29mCreating a Code Review Culture