One of the most impactful work habits I’ve learned is to break up my work into a number of small independently shippable changes. It helps me ship faster, understand the problem better, and spread context.

Shipping small changes helps to clarify my thinking and make sure that I understand the problem. Because if I don’t fully understand the problem, it’s hard to break the work into small pieces that make sense. It decreases the number of changes on my working branch, meaning that I have to hold less context in my head, and rebases are quick and easy. It makes it easier to write detailed pull request (PR) descriptions, because I’m only describing a small change. Since I need to write a larger number of PR descriptions, I get practice explaining the context around the problem, which can help me spot errors in my logic and understand the problem better.

It decreases the time amount of time taken for reviews: small changes are easier to understand and less intimidating to review, so reviewers are more likely to review them right away, in a single sitting. Because reviewers can understand my change, we spend less time going back and forth on little details and more time discussing the actual problem. Since reviewers have an easier time understanding the change, and can give more useful feedback, it is less likely that a major problem will escape notice.

Less time goes by between PRs, meaning that reviewers can keep the context in their head. This increases the speed and quality of code reviews. Shipping a large number of small changes is almost always faster than shipping a small number of large changes.

Shipping more stuff also just gives me more little dopamine hits and a sense of progress that makes me happier.

I keep my changes small not just by planning out my changes beforehand, but by continually looking for pieces I can carve out from my working branch to ship independently. For example, if I need to move a duplicated testing method into a shared helper, I’ll split that off from the current branch and put up a preliminary PR for it (small refactor PRs like this are easy and fun to ship because there usually isn’t much to debate about). Then I’ll go back to my feature branch and rebase on the preliminary refactor branch and keep working while I wait for reviews.

So next time you find yourself hunting down reviewers or feeling nervous that your working branch is getting big, take a step back and ask yourself if you can split up your changes.