Cut your pull requests into halves, then repeat

Small things are generally easier to handle. It is no brainer why humans build methods or tools to break things into smaller pieces. Separation of concerns or refactoring monoliths to microservices serves the same purpose: to reduce the size of a thing to make it manageable by performing less effort. It is the same purpose when contributing your work to a system. That is when sending change requests(or pull requests) into a codebase, keeping the size of the request small enough will benefit you in many ways such as minimizing the chance of adding a new bug and breaking things in production, getting faster feedback, finding bugs easier and quicker.

Having a peer review of your work is not always a smooth process. You may find your work waiting too long to get enough approval before you can ship it. Long living open requests generally deal with a quite complex problem which may take longer discussion or become a hustle to understand… and reviewers will spend a considerable amount of undistracted time to understand it. They will ask a lot of questions, trivial and nontrivial. Addressing all these concerns and waiting for another round of review may take days. When the work is broken down into separate requests, maybe some pieces will be approved immediately or will receive comments that can be addressed quickly. It also helps reviewers as well so they would need shorter time blocks to review the work. So, the smaller the work, the quicker the review process is. It helps both sides, you as the author of the work and the reviewer.

Every change comes with a level of risk like introducing new bugs or breaking things. Especially when the change is complex, errors may be lurking around and unnoticed as the other parts of the work may deplete all the attention of your reviewers. So if the change is as small as possible, like an atomic work, then every part of the change may get careful reviews. Always assume that people have a limited amount of attention and take this into account to tailor your work for review.

Bugs and errors are inevitable regardless of how much we thrive on processes and methods to have a few of them as possible. Bugs may have a varying range of impacts, they can be minor or catastrophic. In general, they are put into the system by programmers without noticing. The way to mitigate the number of bugs is to have fewer code changes each time so that they can be independently tested and in case of a failure, it will be easier to pinpoint where it is caused. When you have many moving parts in a single change, then you have to search the bug(s) in many places. Smaller changes help you narrow down the search later.

Not only in software engineering but in the other areas of life, divide and conquer is a well-known method to deal with complex systems. We need to hone our skills of breaking things into meaningful pieces and tailor peer review requests for reviewers, although it is not going to overhaul all the reviewing process. The variety of benefits usually overweights not having a holistic view while reviewing smaller pieces. You can start trying this approach and see it for yourself where you will receive quicker feedback and have shot living change requests.