I enjoyed reading Dan McKinley’s recent post, Ship Small Diffs, in which he explains some of the benefits that fall out of committing code in very small amounts, perhaps a dozen lines.
My favorite benefit of doing this is the way it gives code reviews a fighting chance of being useful.
Submitting hundreds of lines of code for review is a large commitment. It encourages sunk cost thinking and entrenchment. Reviews for large diffs are closed with a single “lgtm,” or miss big-picture problems for the weeds. Even the strongest cultures have reviews that devolve into Maoist struggle sessions about whitespace.
Looking at a dozen lines for mistakes is the sort of activity that is reasonably effective without being a burden.
In my experience, code review is one of those “best practices” that teams tend to adopt in a sort of “put a check mark here” way where they’ve heard it’s a good thing to do, and lots of good tech companies do them, but they never take the time to do them in a way that actually adds value to their development process.
Submitting a thousand-line diff that traverses many files for code review is almost worse than useless. No one has the time to rebuild the mental context of the person who wrote this pile of code, to a point where they could even hope to intelligently criticize its design.
A code reviewer who receives a diff like this will 9 times of out 10, pull out their LGTM stamp and continue on with a productive activity. If you’re lucky, maybe they’ll notice a variable name is misspelled or something. If you’re unlucky, the reviewer will turn into the world’s most inefficient linter, and point out all the places you used double-quotes instead of single-quotes.
Unfortunately, to get any real benefits out of code reviews, the team must internalize some lessons about breaking down large changes into minimally viable increments. It’s not as simple as just saying, “Yep, we do code reviews.” and patting yourselves on the back.
But…when you get there, the benefits go so far beyond effective code reviews.