Summary: Many companies practice ‘code review’ to reduce technical debt. However, with more thought and care, ‘code review’ can influence company culture to nurture humility, open & positive communication, alignment towards greater good, and respect. This article proposes 3 simple steps to un-tap this latent potential of ‘code review’, which includes introducing 2 conceptual guidelines: ‘situational criticism’ and ‘intent-based criticism’.
Many years ago, the term code review would conjure up the feeling of tardiness in product development. Like ‘light’, which cannot be fully appreciated without ‘darkness’, technical debt, which was expounded in many blog posts, became the ‘darkness’ from which code review shone. Technical debt arises from each new piece of code that reduces the codebase’s overall maintainability and extensibility. This can result from the coder:
Code review brings a pair of fresh eyes, that alleviates (not eradicate) the first 4 problems, and acts as a balance-and-check mechanism for the last 2.
Tangentially, code review also disseminates knowledge about the codebase across the team.
Code review can exert far-reaching effects beyond reducing technical debt, and balancing development release cycles; when done with care, it builds great team culture. It nurtures:
Unfortunately code review and the culture it nurtures does not happen overnight, they demand that we work for it. Fortunately, with a set of coding, and behavioral guidelines, we can unleash its full potential.
Code review, if advocated without supporting mechanisms, usually ends up in one of these extremes:
To overcome these, code review needs a formal declaration of intent (purpose), and a set of guidelines to support the intent.
The code review intent focuses on the good of everyone in order to encourage them to get behind it, and utilize it as a tenet to defend against actions that undermines it. Code review should:
There are 2 types of guidelines (coding and behavioral) required to get everyone on the same page quickly on what preserves the intent of code review, and what constitutes violation. They also become a reference point from which to reconcile differences.
These are well-known coding practices accepted by the community, and they focus on code composition and code style. The former enforces coding principles, e.g., data integrity, which mandates using foreign keys in database tables, etc., while the latter encourages uniformity, which aids readability and comprehension, e.g., code preferences, which documents nitty-gritty like preferring while over for loops. There are many articles on both so I will leave you with a piece of advice:
“Don’t spend weeks pondering which best practices to use; start with any RIGHT NOW, and tweak as the team goes along”
It is easy to bandy about the phrase ‘positive criticism’ but it is too wide open to interpretation, and is overly reliant on the tact and prudence of the giver, which coders may not be naturally blessed with, especially junior ones.
To foolproof ‘positive criticism’, we demand that it should be both a situational criticism and intent-based criticism.
This disarms the criticism from insinuating anything persistent about the receiver, thus conveying a sense of exoneration, making it both easy to give & receive it.
Moreover, it transfers the onus of ensuring that the criticism is indeed situational to the receiver; the recurrence of the same situational criticism is tantamount to a reprimand for being a repeat offender.
Since the intent of code review is to improve everyone involved and the codebase, intent-based criticism has a positive vibe, and should be really useful, making it both easy to give and receive.
Here are a few ‘good’ code review examples that combine both situational, and intent-based code review, and a few ‘not good’ examples.
Would it be easier to understand in the future, if we use a switch statement here?
In this part of the code, would using a factory pattern make it possible to handle new use cases in the future?
It is good practice to use switch statement instead of multiple ifs.
You should use a factory pattern to ensure code can handle new uses cases.
Note the good code review examples also are often suggestive, inviting discussion, or formatted into question form.
If you are big on using data to power your company, and are a believer in continuous real-time feedback (instead of the hand-waving, “we have an open-door policy where you can come in and tell us about your problem anytime”), get started with a single-click on re:Culture to keep a pulse on how well the team is adopting code review.
We hope that you are convinced and excited about the potential role code review can play in building a great company culture. With 3 simple steps of formalizing the intent of code review, implementing coding guidelines with community best-practices, and implementing behavioral guidelines with situational and intent-based criticism, you have all the tools to transform your company culture.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
Create your free account to unlock your custom reading experience.