Balancing the boy scout rule with the “do one thing” rule
The boy scout rule
Uncle Bob (or best-selling author Robert C. Martin) phrased it like this:
THE BOY SCOUTS HAVE A RULE: “Always leave the campground cleaner than you found it.” If you find a mess on the ground, you clean it up regardless of who might have made it. You intentionally improve the environment for the next group of campers.
From 97 Things Every Programmer Should Know by Kevlin Henney
The “do one thing” rule
It spans many areas and can translate to many other rules, such as the Single Responsibility rule, the Single Source of Truth convention, or the Don’t Repeat Yourself principle.
The conflict
While working on some part of a product, you will inevitably run into things you can improve or fix. If you want to be a good scout, you will want to fix them. The problem: they have nothing to do with your work. Your PR no longer does just one thing, and finding those outliers in a PR has a name: scope creep. Originally a term from project management, it also applies to code reviews.
We will need to divide and conquer.
Strategy 1: multiple PRs
It is the most obvious but also the one that has the most overhead. Engineers tend to take the shortest path, and taking the time to create multiple PRs from multiple branches is a headache all of us will probably skip. The more minor the fix, the less likely we are to make the effort of creating an entire PR (and all the overhead that comes with it — code reviews, CI pipeline, deployment) just for it.
Strategy 2: one PR, self-contained commits
I use this strategy when the load of reviewing one PR is too much for me to split the changes into multiple PRs.
Inform your code reviewers about the best way to read this PR: instead of one giant list of changes, this kind of PR is best reviewed commit-by-commit. This strategy requires thinking about your commits so that each of them has its context and serves as a whole “unit of change.”
I find that it’s beneficial not only for the review itself but also for looking at the bigger picture of your task. It makes you think in logically connected chunks of work, and who doesn’t want tighter commits?
