Communication for Developers
summary
Be explicit: state what you’re estimating (scope), the assumed developer assignment and availability, and an uncertainty factor — e.g. 55 man-days × 1.2 uncertainty leading to a date given one developer four days/week. For PRs, pick concrete reviewers and a deadline — ask 2–3 reviewers for one approval — keep PRs small, highlight key files, label drafts and avoid rebasing/force-pushing during review. For async messages use a TL;DR at the top, target recipients, explain why/when, and leave breadcrumbs — link to Jira/GitHub/Slack.
AI-written summary · about
chapters (10)
- 0:00Introduction and motivation
- 2:58Personal communication struggles
- 4:46Estimates as communication problem
- 9:44Problems during implementation
- 14:46Coordinating releases
- 16:17Pull request review process
- 24:05Everyday communication tips
- 33:52Principles of effective communication
- 39:12Cost and culture of communication
- 40:42Q&A session
related talks
47mCommunication for Developers: estimates, code reviews, and other hard problems
34mHow to effectively communicate to Developers/PMs - A guide for developers and project managers
33mThe Creative Developer
29mThe Art of Humanizing Pull Requests (PR’s)
22mHow to be an inefficient developer?
40mInvesting in the Future: Unlocking the Potential of Junior Developers
01h 01mLies Developers Tell Themselves
01h 05mGetting Good (or Better) at Code Reviews