There are a myriad of benefits of smaller PRs with smaller line change deltas:
- easier for reviewers, not only in sheer amount of code to review, but also in the ability to provide useful feedback or start a discussion around different architecture patterns
- lower chances of bugs creeping in
- simpler to refactor and iterate upon
- encourages the code author to think more iteratively (e.g. what is the API I am trying to add right now? What will it look like when I'm done? Is what I'm doing extensible? Will it be suitable for future extensions, etc.)
- more synonymous with a CI flow; it is better to ship multiple small things that can easily be cherry-picked or reverted than it is to ship big PRs that are harder to debug and roll back
One pitfall to small PRs is people feeling like they can't move ahead or build on top of code that is up for review.
We're all pretty good at reviewing open PRs multiple times in a week for the most part (I sucked at it last week), so I don't think that is a big issue. People are also far more inclined to spend 20-60 minutes reviewing something small, as opposed to having anxiety around reviewing something huge, which leads to procrastination. Keeping PRs small encourages a very rapid review process.
Another thing that will help remove this pitfall is people's confidence and familiarity with Git rebasing. Knowing how to make changes on one branch and keep a separate branch rebased on top of it is a powerful skill. It allows you to have multiple branches open at any give time in any given dependency order. The hardest part about this is dealing with rebase conflicts, which shouldn't be too difficult if we are keeping PRs small.