While You're In There ...

When you’re in the middle of a complicated change and you come across something isn’t quite right, but doesn’t impact the work you’re doing, what do you do? What about if you’re adding a new capability and you spot the cause of your personal annoyance? It could be a simple misspelling, incorrect documentation, or something more substantial, like common code that everyone agrees should be refactored out, but no-one has done. You’re right there. Everyone would agree it should be done.

Do you make the change? Do you make it in the same git commit? Do you make it in the same Diff/PR? It depends. Maybe. No.

It depends on the change. It depends on the cost of the change itself. Will making the change substantially impact your ability to deliver the value you’re trying to add? Will it cause rework/changes to other things that wouldn’t be impacted if you didn’t make the change?

It also depends on the difference in the cost of making the change now or later. Making the change is a context switch from value you’re trying to add. Depending on the scope, that could be a pretty large cost, but if the change is contained it’s a small cost. And it depends on the cumulative costs of whatever context switches got you to where you are. If you’re 7 layers of abstraction deep in the code and your mental model currently holds that state the cost to rebuild that context could be significant. On the other hand, if you’re working on code you work on regularly and not deep behind abstractions/helpers then the cost would be small.

Think of it this way. You go to the grocery store and buy everything on your list. While going up and down the aisles you notice the crushed walnuts and think they would go good in the salad you already have the ingredients for. You could just add them to next week’s list. After all, the salad will be good without them. But it will be better with them. And you certainly don’t want to get home, unload the car, then turn around and drive back to the store, buy the walnuts and then drive home again.

So the “It depends” is the cost/benefit calculus of not just the benefit of the change, but the opportunity cost (what you’re not doing instead), and the sunk cost of the setup that brought you to this point.

Maybe it should be in the same commit. Changing spelling in a comment? Sure, just add that to the current commit. Refactoring/changing function arguments? Use a new commit (or two). Commits are cheap. They’re your friend when something doesn’t go the way you want. Rather than go back to the beginning of the level and fight through the dungeon to where you are, just back up a couple of steps and try again. And if you’re not sure where it went wrong, there’s always bisect

No, don’t use the same Diff/PR for the two changes. Any time your commit message includes the phrase “and while I was there” stop. Think about what you’re doing. You’re almost certainly doing two separate things. So make them separate Diff/PRs. In that way they’re like git commits. Not quite as cheap, but they have many of the same benefits. So take advantage of them. Future you will thank you.