Pull requests are bad, actually
I used to be a big advocate of pull requests as a collaboration tool, citing the usual reasons:
- Maintaining code quality and consistency
- Two pairs of eyes are better than one for spotting bugs
- Allows controlled release of features into
main
However, I’ve come to believe that the first two points are more effectively solved by pair programming. For example, in what situation are you most likely to spot a bug? While reviewing a 1000+ line PR, or as it’s being typed out? The same thing goes for suggesting alternative solutions to problems; it’s hard to give good feedback, but it’s much easier before your colleague has committed to a solution. Besides, there’s nothing stopping you from soliciting feedback on a feature branch; I just don’t believe it should be mandatory.
Some might say that I’m building a straw man argument, and that 1000+ line PRs are an anti-pattern. They might point to things like stacked diffs and claim that this solves the problem of big PRs. But if you take the arguments for stacked diffs to their logical conclusion, you end up with pair programming and trunk-based development.
If you’re used to working with pull requests, this will probably sound completely crazy (this was my initial reaction as well). But consider this: What problem did pull requests solve in your organization? Does anyone remember? Was there even a problem in the first place?
I’m not saying that PRs should go away completely—they are very useful for collaborating in low-trust environments. However, if your workplace in a low-trust environment then you need to fix that.