In Defence of the Pull Request
Code reviews aren’t the developer’s primary responsibility, and often there is more than one round of changes to review. There’s always one person in the way to wrap up work, leaving snarky comments. Pull requests take time, resulting in long-lived feature branches and violation of continuous-integration principles. And, despite thorough reviews, bugs still make their way into production. Pull requests are neither efficient nor effective; they slow down delivery and contribute to toxic environments.
I came across two articles recently, arguing this way: No code reviews by default by Raycast’s Thomas Paul Mann and Are Pull Requests Holding Back Your Team? by David Masters. I’m sure there are more.
Both authors make valid points, but I disagree with their notion of the pull request’s purpose and how they contribute to a team’s culture. Code reviews aren’t a means to control co-workers solutions. They don’t exist for senior developers to decide what gets shipped and what isn’t, or for them to patronise junior developers. We have pull requests and code reviews to enable teamwork.
A pull request is a way to ensure we ship code that works. It’s a chance to verify that changes address the requirements outlined in the ticket and to check against potential edge cases. Humans make mistakes. A reviewer won’t find all the bugs, but the second pair of eyes helps find and fix more.
