Editing

# 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](https://newsletter.pragmaticengineer.com/p/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](https://trunkbaseddevelopment.com/).

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.