2024-04-16 - Cameron Harder-Hutton
The Google Engineering Practices Documentation has a principle that I like:
"In general, reviewers should favour approving a code review once it is in a state where it definitely improves the overall code health of the system being worked on, even if the code review isn’t perfect."
In practice, I take this a bit further.
I try my best never to withhold code review approval on code that works. Instead, I approve and ask the requestor to follow up with the changes I want to see. The caveats are: it needs to have tests and I need to think it's safe to deploy.
So... why?
Give trust first
When I say this, most people say: "what if I don't trust this person to follow up?" The answer I give, and the main reason I do this, is because I believe in giving people the trust first. It builds relationships and people like it when you trust them.
You can deliver features more efficiently.
Going back and forth for 3+ revisions on a code review, and being set back an hour or two is fine, but sometimes it's not just a couple of hours.
If you factor in poorly overlapping timezones, a flakey test in your CI/CD pipeline that requires a few retries and time blockers on your pipeline to prevent deploying during peak hours, I've seen it take a week to merge and deploy a change that was 'working' on the first revision.
Obviously this is the worst case scenario, but I like to keep my standards the same no matter the circumstances of the review.
It encourages people to make smaller code reviews.
The more friction (good or bad) during the review process, the more changes people will lump into the same review. Small code reviews are easier to review, faster to get feedback on and just generally safer. This article and this book are good resources on this.
Your mileage may vary and I'm sure this won't work for everyone, but give it a go!
Have any thoughts? Send me an email!