The Art of Humanizing Pull Requests
summary
Advocates breaking large changes into small PRs, claiming small PRs merge faster and are easier to revert; demonstrates a React Native feature using react navigation and shows GIFs produced with Lice cap and Get cap to speed review. Recommends write tests as documentation and use a PR template with checkboxes when CI is missing. Notes a 250‑line PR forces 3–4 hours per reviewer and often fails to land, so empathy plus concrete suggestions and git emoji commit tags actually improve outcomes.
AI-written summary · about
chapters (8)
- 0:00Intro
- 1:26WHAT IS A PULL REQUEST (PR)?
- 8:15TESTS ARE DOCUMENTATION OF YOUR CODE
- 10:39REGARDLESS, YOU SHOULD WRITE A TEST.
- 13:35FAMILIARIZE YOURSELF WITH THE CODE
- 17:50DON'T LITTER CODE WITH NITPICKS
- 18:26HOW TO RESPOND TO FEEDBACK?
- 25:06SMALL THINGS CAN HAVE A BIG IMPACT
related talks
29mThe Art of Humanizing Pull Requests (PR’s)
21mContinuous Improvements of The Code Review Process
29mThe art of humanizing Pull Requests (PR’s)
18mHow to effectively create and review PRs
28mPull Requests: Merging good practices into your project
38mPull Requests and Reviews for Good
21mA Guide to Perfecting Pull Requests
30mEffective Pull Request Reviews