Accelerate your software engineering career by sending small diffs

Every software developer gets carried away once in a while. There is this new cool, top requested feature and we want to code it quickly, so we disappear somewhere and, after a few weeks, we drop this huge diff (a.k.a. PR, CR) like a bomb. We are so proud of our work! Somehow, our team members do not share our level of excitement. Why is that?

Well, it turns out that huge diffs create a number of problems that make lives of both the author and his team harder:

1. Getting huge diffs reviewed is challenging
   Finding someone willing to review a huge diff is difficult. Once this person is found, the progress depends on them finding a lot of time to properly review the changes.
   Occasionally, a huge diff draws attention from multiple reviewers leaving tens of conflicting comments. Each new iteration addressing these comments only sparks more comments.
   
2. Keeping huge diffs up-to-date is hard
   While a huge diff is being iterated on smaller diffs are merged daily. This may result in merge conflicts which take time to resolve, create risk of introducing bugs due to bad merges, and make it harder to understand what changed between iterations.
   
3. Huge diffs rarely receive good feedback
   Understanding of a huge diff is hard and time consuming. Reviewers often focus on less relevant but easier to understand details. Sometimes they give up and just rubber stamp the diff without leaving any useful feedback. In either case, obvious issues can easily sneak into the product.
   
4. Huge diffs make it hard to pivot
   Sometimes, someone finds an issue that forces changing direction. In case of a huge diff it means a lot of time was spent on writing code that now needs to be rewritten or thrown away.
   
5. Merging huge diffs may have significant negative impact
   When a huge diff is finally merged, it often wreaks havoc across the team. Many ongoing changes have to be redone, the number of reported issues increases significantly, dashboards and alerts get broken, etc.

The alternative to huge diffs is splitting the work to smaller, more manageable chunks. Each chunk should be a logically complete piece of functionality that can be independently merged and brings the feature closer to completion. It may feel like more work but it is a much more effective approach:

• code reviews are faster as small diffs take less time to review
• different diffs can be reviewed by different people – there is no longer a bottleneck of a single reviewer
• smaller diffs are easier to understand so they get better feedback
• it is possible to work on the next diff while having one in review
• changes are localized so the risk of merge conflicts is reduced
• course correction, if necessary, is easier because there is not much code impacted

Getting used to splitting the work to smaller chunks can be hard at the beginning but once you get used to it, it will become natural and your productivity will soar!