Why Breaking Your Code Changes into Smaller PRs is Essential for Developer Productivity and Collaboration

"I can't review this PR any further because it is too big..." That was my lead feedback on one of the PRs I sent in for review some weeks back at work.

As a developer, you're probably familiar with pull requests (PRs) and chances are that you've sent a few yourself or also had the opportunity to review other developers' PRs. But if this is your first time hearing about a pull request (PR), that is also fine.

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch__ Github

In clearer words, a pull request is a proposed code change that is submitted by one developer for review and approval by another developer or team of developers.

PRs have become a major and important part of software development, as this provides various developers and teams to collaborate and review each other's code changes before they're merged into the main codebase. This means, that developers can collaborate and work on multiple projects despite them being in different places or time zones.

Like the popular Uncle Ben saying, "With great power comes great responsibility", the same thing goes for PRs. However, many developers misuse PRs by making the mistake of submitting large PRs with changes that span across multiple files, features or even entire projects.

Although this might look like a time-saving strategy and the opportunity to do all your work in one place, in reality, you'll most likely end up in a situation where you've written so much code, that is difficult to review by your teammates, which in turn slow down the development process and even decrease the quality of the whole codebase.

Why? The Big Question.

I am going to discuss some reasons why breaking your code changes into smaller Prs will aid developer productivity at your workplace, and make collaborating with other developers on your team or other teams a pleasant experience.

1. Smaller PRs are easier to review

A PR with multiple changes across multiple files or features can be challenging for your teammates or Lead to review. This makes it for the reviewers to understand the scope and the impact of each change.

When a PR contains multiple changes, it can be challenging for the reviewer to understand the scope and impact of each change. This can lead to misunderstandings, errors, and even conflicts between team members. Chances are you will end up with so many requested changes from your teammates or Lead because of the huge PR you submitted. And trust me, tackling one requested change after the other for just one PR is not a pleasant experience.

But by breaking your code changes into smaller PRs, you enable whoever is reviewing your code to focus on a specific feature or bug fix, making the review process faster, more efficient, and more accurate. With this, you can clear up the engineering team roadmap faster.

2. Smaller PRs are less intimidating

One of the ways to onboard new team members is to let them read and review other developers' code, a PR in this case. Although most cases, new members won't have any inputs, by reviewing PRs they get to understand what the developers are working on and give them a better understanding of the codebase.

But in cases where team members send in large PRs, this can be overwhelming, for new team members or developers who are not familiar with the codebase, thereby creating an entry barrier and discouraging collaboration.

When you break your code changes into smaller PRs, that are easy to understand, it makes it easier for team members to understand the changes you are making and contribute their feedback and ideas.

3. Smaller PRs are easier to test

A PR with multiple changes across different features and bug fixes is hell for developers to test. This makes it more challenging to isolate and test each change separately, which in turn makes it difficult to identify and fix bugs.

4. Smaller PRs make you feel good

There is this euphoric feeling you get from the completion of tasks. This feeling gives you the eagerness to get other tasks done asap. Merged PRs give developers this feeling also. Instead of sending in a huge PR that can take days to review and implement requested changes, smaller PRs are reviewed easily and merged on time. And nothing feels better than seeing your code live in a project.

Conclusion 🏁

Like the famous quote "Little drops of water, little grains of sand, make the mighty ocean and the pleasant land.", we've seen how breaking your code changes down into smaller PRs is great for developer productivity and fostering healthy collaborations between developers.

I am sure there are other reasons why smaller PRs are the way to go, so feel free to some of your "whys" in the comments.

Adios👋