Communication for Developers: Estimates, Code Reviews, and Other Hard Problems
summary
Concrete habits matter: give estimates as dev days plus an 1.1 to 5 uncertainty factor, state assumed developer availability and exact scope so the number means the same to both sides; make PRs reviewer friendly by targeting specific reviewers (need one approval ask two), adding a one‑line TLDR, linking GitHub issues/commits as breadcrumbs, setting a deadline like merge it by Friday, and avoid no force pushes during active review so reviewers can follow changes.
AI-written summary · about
chapters (35)
- 0:00Introduction
- 3:35Shannon model basics
- 4:37Estimates as communication
- 7:11Communicating estimates
- 9:20Estimate vs commitment
- 10:01Language for non-tech
- 11:08Code comments future
- 12:55Leaving breadcrumbs for future developers
- 14:00Open work communication
- 15:25Release coordination
- 16:34Finding PR reviewers
- 17:39Review deadlines
- 18:25Reviewer-friendly PRs
- 19:51Rebasing during reviews
- 20:37Constructive PR reviews
- 21:42Conventional comments
- 22:04Avoiding jerk reviews
- 23:51Picking review battles
- 24:56Daily comms pitfalls
- 25:41Repeating messages
- 26:47Targeted questions
- 27:35Justifications in requests
- 28:38Deadlines for info
- 29:19Giving the responses you want to receive
- 30:45Tone and smiles
- 31:51Harsh messages
- 32:36Async formatting
- 34:03Meeting costs
- 35:07Core comms principles
- 37:15Formalities and language
- 38:39Brevity and readability
- 39:42Open channel comms
- 40:49Directness vs effort
- 41:11Cultural differences
- 42:15Q&A
related talks
28mCommunication for Developers: estimates, code reviews, and other hard problems
22mContinuous Improvements of The Code Review Process
39mEffective Code Review
28mPull Requests: Merging good practices into your project
22mBringing A Healthy Code Review Mindset to your team
34mHow to effectively communicate to Developers/PMs - A guide for developers and project managers
53mCode Review - how to do it better?
05mAn Effective Code Review