Communication for Developers: estimates, code reviews, and other hard problems
summary
Estimate conversations use a concrete formula: state the scope + developer days + uncertainty factor + availability to produce a date both sides mean, and call out whether the number is an estimate or a commitment. For PRs, pick reviewers conservatively — pick three reviewers for two approvals — mark the few important files with inline comments, label comment intent (e.g. question / nit / blocker), avoid noise like avoid force-push after publish, and link tickets, Slack threads and StackOverflow threads so future investigators find context.
AI-written summary · about
chapters (16)
- 0:00Introduction to communication
- 1:50Why communication matters
- 2:55Shannon communication model
- 4:18Estimates as communication
- 8:30Adjusting content to audience
- 9:35Code comments as future messages
- 11:20Linking context with breadcrumbs
- 12:43Building in the open
- 13:46Coordinating releases
- 14:08Pull requests and reviewers
- 17:43Reviewing with empathy
- 19:54Everyday communication tips
- 21:21Crafting effective questions
- 22:23Giving responses mindfully
- 24:29Wrap-up and key principles
- 26:58When to apply communication rules
related talks
45mCommunication for Developers: Estimates, Code Reviews, and Other Hard Problems
34mHow to effectively communicate to Developers/PMs - A guide for developers and project managers
22mContinuous Improvements of The Code Review Process
39mEffective Code Review
44mInspect & Adapt, then What?
47mOpen discussion: Premises and promises of code review
47mCreating efficient, accurate, software estimations
26mEnhance Developer Experience by community