Lately I’ve seen several people reacting against the idea of pull requests, on the basis that pull requests are a mechanism to safeguard against untrusted code. Consider this post from LinkedIn:
[Pull requsts are] about distrust. Apparently people don’t trust their team mates to do the right (enough) thing.
A similar sentiment can be found in Kief Morris’s article Why your team doesn’t need to use pull requests.
I’m willing to accept as granted that pull requests can be useful in low-trust situations, such as vetting code changes from a stranger on the Internet.
But the apparently widely-accepted view that PRs are only useful in low-trust situations just baffles me. Perhaps this is a reaction against abusive PR reviews, which are a serious problem on some projects. PRs should never be used as an opportunity to berate people with less experience or different opinions. PRs should be used in a “trust but verify” mindset.
I find pull requests so beneficial that I use them on solo projects. I think it’s hard to make the case that I do this out of a lack of self-trust.
So why do I advocate the use of pull requests, even in high-trust situations? Here are a few:
- A fresh set of eyes (or in the case of a solo project, a fresh view) often catches small oversights. And the best of us always have small oversights.
- It’s a great mentoring opportunity. I’ve learned a ton about how to improve my code from code reviews, even when my original code would have worked as intended.
- It helps reduce the bus factor. On a team project, there is immense value to be had in two (or more) people understanding all code.
- More readable code. Code that works is often unintuitive. Getting someone else to simply say “WTF?” can be enough to trigger a refactor for better readability.
Are these about mistrust? I don’t think so. Although if I want to play the Devil’s advocate, I could say that I mistrust myself, and I mistrust human nature. If that’s the mistrust I use PRs to overcome, then okay, I’d be willing to say that PRs are about mistrust. But that level of mistrust is healthy, in my opinion. We can trust our peer’s motivations, and still verify their code.
Top comments (2)
Agree. For example on our team we frequently open a Draft PR as soon as the first commit is pushed. The review is more continuous that way and it’s also normal to have several Drafts in progress by a single developer. That way the blocking of a single PR by review is not as big of a deal. People are in different time zones after all. A few other thoughts here - dev.to/appland/beginners-mind-how-...
Draft PRs are good, although if there are may of them, I start to wonder if the PRs themselves are too big.
I tend to create many PRs per day, often containing only a single commit.
Large PRs usually man you're not doing continuous integration. jhall.io/whatisci/