“Ensuring code quality” and pretentious approvals are a boring way to think about PRs and code review on an team. Here are more fun things that I love about pull requests.
A pull request is an opportunity to…
Reviewing other people’s code can let you pick up language features you didn’t know about, introduce you to different parts of the system, or unveil business logic you haven’t bumped into yet.
Commiting code for someone else to review is an awesome way to demonstrate something you recently learnt. Bonus points for writing helpful explanations and sharing useful links in PR comments!
Why solve problems alone when you can be faster and smarter together?! Collaboration though discussions on a PR can be pretty close to pair programming, just a bit more asynchronous.
Share Ownership ⚡️
Even a swift glance over small changes means more than one person was involved. Over time that can contribute to developers feeling responsible for larger parts of the code base.
Reviewing a PR is perfect for giving positive feedback to co-workers on something specific and to demonstrate that someone cares about the work they have done. Sprinkle those comments with kudos and emoji.
Sometimes I have an idea, with no clue if I’m on the right track. But instead of churning out essays to ask in chat, I can comunicate way more efficiently with code: “Will changing this line do the thing?”
Know Your Team Mates 🦸🏻♀️
Build deep understanding of each others competance. Who on my team will think something different than me about this issue? A PR last week creates a base to bounce off new improvements this week.