Write Small Code Changes

Hi 👋, everyone, this is Kevin sharing another article from The Software Engineer Weekly. Every week I share insights into working as a software engineer and the lessons I’ve learned in under 5 minutes.

This week we crossed 4,900+ readers! 🎉

---

Write small code changes. This is something I wish I had learned earlier in my career for many reasons. There are many advantages to writing small changes. Here are five reasons to keep your changes small.

1. Faster Reviews

No one likes reviewing large code changes. One simple reason to write smaller changes is to receive faster reviews. Not only is it hard to convince teammates to review large diffs (i.e. pull requests, change lists, etc.), but it’s also very likely that they won’t scrutinize your changes as thoroughly potential missing errant code in the process — entirely defeating the purpose of code reviews. Small changes also allow your reviewers to have better context around what your changes accomplish, something that’s particularly helpful in ensuring you’re healthily contributing to your codebase.

2. Increased Productivity

Keeping your changes small also helps increase your productivity. When you’re tasked with large projects getting started can be daunting. Breaking up the project int0 smaller chunks that can each be delivered in isolated changes helps ensure you can move quickly. More, smaller tasks help prevent yourself from becoming blocked from moving forward ensuring you can continue making progress on your project. Small changes are also more easily chained together and easier to modify as you receive comments from reviewers. The larger your changes are the greater the chance that you’re doing something incorrectly. Smaller changes help ensure timely feedback that is easily corrected.

3. Fewer Comments

The amount of comments you’ll receive during code reviews is another strong incentive to keep your changes small. Sending a reviewer a thousand-line diff is all but guaranteed to result in two possibilities: zero comments or endless comments — both of which are concerning. Zero comments on a large change could be indicative that the code wasn’t thoroughly reviewed. Lots of comments on a large change could be difficult and expensive to refactor. Small changes help ensure you receive a high-quality review and manageable feedback if necessary.

3. Fewer Bugs

Small changes also result in fewer bugs. The chances that you introduce a bug into your codebase increase with every line of code you write. Small diffs help you and your reviewers catch any problems before they’re submitted. Similarly, if you do submit a buggy change, rolling that change back is easier if your code has affected a smaller portion of your codebase. Diagnosing the root cause of a bug is also much easier when changes are small. Once you find the problematic diff, isolating the problematic line(s) is often trivial in smaller changes. On the other hand, finding the problematic change in large diffs is much like finding a needle in a haystack.

5. Increased Code Stats

While I don’’t agree with it as a measure of engineering productivity, some companies choose to track individuals’ code contributions such as the number of code changes submitted, the number of lines changed over a specific period, the average number of comments received on reviews, etc. Smaller changes help you increase these statistics concerning your throughput and code velocity and decrease the number of comments you receive per review. Help increase my ~code stats~ by leaving a like on this article.

In the spirit of small changes, I purposely chose to keep this article short; however, there are three errors throughout this article, let me know in the comments below if this post was small enough for you to catch all of them!