As software engineers, we all want to get things done quickly and efficiently. But sometimes, we focus too much on short-term results and end up working harder in the long-term. In this post, we'll explore why you shouldn't just do the bare minimum when implementing code changes and why you should make seemingly unrelated changes while you're there.

Firstly, let's define what we mean by "bare minimum" code changes. Examples of this might include implementing a change in a hacky way instead of refactoring first and then implementing the change in a clean way, or ignoring a minor bug in a file you're working in because it's not related to your current work. While relentlessly focusing on the change you've been assigned to make can get the change out more quickly in the short term, it will cost your more time in the not-actually-that-long term.

The main reason that doing more at once is important is that getting the context to make a change is the most time-consuming part of doing it. Writing the actual code to make a change might only take a few minutes, but understanding the system, finding the place to make a change, understanding the existing code, and deciding on the best fix can take hours (or days!). Because of that, it's much more efficient to make any other refactorings and fixes needed at the same time, while you have all of that context in your head. If you have to come back and make another change later, you'll need to get all of that context again, which is orders of magnitude slower than doing it while you already have the context.

But how do we balance the need for speed and getting changes done quickly with the usefulness of thorough solutions so we won't need to come back? The way I do this is to fix unrelated bugs if the solution is obvious (otherwise, documenting the bug for later), and to do refactoring if the total time spent won't be much longer.

It's also important to be aware of potential downsides to this approach so you can recognize and avoid them.

The most obvious case where you shouldn't do this is when a issue really absolutely must be fixed right now. If your production systems have a serious bug, the short term really does matter a lot more than the long term. Once you've fixed the bug, consider using the context you gained in the fix to improve the codebase, but don't put a production fix on hold for an hour to do a cleaner fix.

Another issue is that you can get sucked down a rabbit-hole trying to fix something much harder than you expected. Sometimes it looks like there's a small problem that you can trivially fix or refactor in only a few minute, but then an hour later you notice that you're still going and the problem isn't getting any smaller. When this happens, it's important to recognize it and stop. Discuss with the team, document what you learned, and consider whether it's worth doing the change even though it's much larger than expected (sometimes it really is worth it to re-arrange a sprint to let you fix something while you have context, but sometimes it's not).

Also keep in mind that unrelated changes can make code review more difficult. To minimize this cost, you should make larger unrelated changes in separate commits and pull requests so they can be reviewed individually (learn git rebase -i if you haven't already). Sometimes you notice a bug that's not really worth a separate code review, and it can be ok to just include it in your main pull request. I try to avoid doing this with changes that are more than a few lines, unless they're purely formatting, and I make sure to call them out in the pull request so people won't be confused.

One last thing to be aware of to not get overzealous with this. If you don't understand the code you're fixing, you can accidentally introduce new bugs. If you notice code that's confusing but not clearly a mistake, it can be better to discuss it with the team or make a note to look at it later, rather than making changes you don't understand and introducing bigger problems.

In conclusion, while it might be tempting to just do the bare minimum when implementing code changes, taking the time to fix other problems and refactor when appropriate can save you time in the long run. Remember that writing code changes is often only a small part of the work involved, and that understanding the context is key. By taking a more thorough approach to your code changes, you can increase the long-term velocity of your team at only a small cost in the short term.