One small thing to make a greater impact

If you’re making anything with software these days then there’s a good chance that you want to make the lives of people who use it a little easier, a little better or even a lot better.

Even if you don’t, you want the work you do each day to have an impact.

The question is, how can you optimise what you do each day to have the greatest impact?

Over the last 10 years, I’ve worked with a lot of different teams on a lot of different products. This has given me a great opportunity to see what works well and what doesn’t.

Teams having the highest impact shared similar philosophies and ways of doing things. One of these philosophies has a return that far outweighs the effort required to make it happen.

It’s easy to fall into the the trap of believing greater impact requires greater change.

Pressure to ship

So, you’re working on a product, and whether you’re the boss or you’re working for someone else, there is a strong desire to ship a new feature or a fix to something already in production.

Your team (if you have one) is as busy as you and have very little time to help in some form of code review. At the same time, you know that once they do help there’s likely going to be a long discussion about the “best” way to do whatever it is you’ve already done.

After spending a few days working through your feature, you are ready to ask for review. 1200 lines of change seems reasonable, after all 30% of them relate to test artefacts like mock JSON response payloads.

You’re a responsible team member and like to leave code better than when you found it. So you took the opportunity to fix a couple of small things at the same time.

Finally you’re done. You submit the pull request and sit back and watch the comments flow.

At this point one of two things happens. First, nothing. Everyone is busy and they don’t want to context switch to review your code.

Or second, the comments do come in thick and fast but you feel frustrated because they all seem to miss the point. Why don’t they get it?

There is a better way and the good news is that it’s simple. Unfortunately it appears to be harder to do in practice than at first blush.

Make small changes

It sounds so simple but small changes are an overlooked superpower of high performing teams.

Making small changes is actually a lot harder than it sounds. It requires more work on the part of the author of the code. It takes more thought when looking for the edges where you can break your change apart.

But, it is so worth it.

Greater impact is found in shipping consistently.

When you don’t do this, you make the reviewer do this work in their head. Every time they read the code. Both now and in the future.

One of the ways of highlighting why large changes are hard to review is the fact that they often take you a while to create in the first place.

If you spend a week or more working on a specific change, is it reasonable to expect someone else to understand the solution you’re presenting within a single session of review?

Regardless of how well they know the codebase or how familiar they are with the feature you’re working on, they will need more time.

Sure, a well written description for your change will help in explaining the context around the choices and help the reviewer avoid considering alternatives.

And while this can definitely speed up the review process, there will still be a significant investment required for review relative to the investment you made.

To ship consistently, we make smaller changes so we can have more confidence about the change.

The other thing to consider is the value of your git commit history.

I have frequently encountered the scenario where I read the commit that introduced a specific code change only to discover that it was added by a seemingly unrelated commit. No explanation. I’m left wondering “Why did they do it like this?”and “I hope nothing breaks as a result of me changing this”.

Don’t do this to yourself or to others in your team. Protect your commit history and you will reap the benefits in the future.

There’s no way I can split this up!

After being immersed in a change for any length of time, it’s common to have this reaction.

The simple test I use to decide if any individual change should be part of the whole is to ask, “Does the description of the commit explain why this change is here?”.

If not, then move it to its own pull request.

I recently did this with a change I was making that was coming in at 500 lines. Now 500 lines sounds reasonable right? I’m pretty sure I could make a case for why they were all required.

When considering whether the description of the commit covered some of the changes, it became clear that I could move some small refactors and improvements that were incidental (but necessary) to the feature I was working on.

A single 500 line changeset turned into 4 separate pull requests.

This definitely took me longer. Both in creating the extra pull requests and getting them through our process of review.

The positive side of this is that the rest of the team were able to give me effective review on each of these smaller changes. Overall, we came away with a better understanding of why and how the product changed.

✌️

The next time you are preparing a new change to your product, consider the benefits of turning it into a series of small changes and see how it works for you.

I’d love to hear other people’s approaches, join the discussion in the comments.