A friend got stunned during a conversation last weekend when I shared how we do code reviews at LOGIC. His approach involves providing gentle proposals and preferring neutral-toned comments over rejecting (requesting changes from) a Pull Request. Our approach is direct, non-personal and honest code reviews. Any work not meeting our standards is not shipped. This is necessary to achieve greatness.
For greatness, we need the best ideas and implementations to reach the surface. The only way to achieve this is by sharing our honest take on whether a piece of work is in line with our shared values and moving forward accordingly. There should be no hesitation whatsoever in throwing away any piece of work that fails to meet our standards. It does not matter how big it is or how much time we invested in it, it is not and should never be personal — it’s all about the quality of the work. At the end of the day, the worst-case scenario is learning a very costly, yet even more valuable lesson.
A good analogy for this is the peer review process of scientific publications in respected journals — something I got to learn from my partner, who is a scientist. Reviewers in great journals are expected to be relentless, even with details that might seem tiny, when there is a chance to affect the final sentiment of the candidate publication. This is even true in open-source. Welcoming contributions does not mean that anything that does not make the cut will be accepted. It should not.
Also, at the risk of stating the obvious, this by no means encourages being impolite. Being impolite usually makes things personal and diverts attention from the most important priority: the quality of the final product. Pointing out why a technical choice serves or undermines the final goal - and making the call on whether it makes the cut - has nothing to do with impoliteness.
Finally, this applies beyond just the final product, especially when it comes to productivity. In one of his latest tweets, Uncle Bob could have not put it better:
A team who allows messes to persist in their code will gradually slow down to a tiny fraction of their potential productivity.
When presented with work to review, share your honest opinion directly and if you are responsible for the final product, make the call to not ship it if necessary. It’s better to be remembered as someone who helped people grow, rather than just for saying nice things.
Go for greatness.
