Why your team doesn’t need pull requests
Using pull requests for code changes by your own team members is like having your family members go through an airport security checkpoint to enter your home. It’s a costly solution to a different problem.
Working in a rhythm of coding, pulling, testing, pushing, and getting feedback from integrated tests several times a day is electrifying. And it isn’t possible with pull requests that introduce a human delay into the rhythm.
It's far more important to have a team that trusts each other and feels confident to push changes fast than it is to have gatekeepers whose role ends up being one of needlessly putting breaks on a team for no justifiable reason.
The PR-based workflow still common to many engineering teams is at best inefficient, at worst fundamentally broken. In the journey of code from developer fingertips to user’s hands, the review stage of Github flow is usually the most drawn out and least productive. Code that could be delivering value to users is languishing on a branch, waiting for another engineer to pay the price of context switching to look at it. Add in the feedback cycle of comments being left, then being addressed, then looked over again — a cycle potentially repeated multiple times — and this stage of the voyage looks like a veritable doldrums.
My biggest concern regarding pull requests is they block the flow of work. It is a gating process that blocks the delivery of functionality. The code review becomes definitive to merging and releasing. This again increases the time to market and introduces a non-negligible opportunity cost. Finally, it disables timely feedback from production.
