Summary: _Many companies practice ‘_[_code review_](https://hackernoon.com/tagged/code-review)_’ to reduce technical debt. However, with more thought and care, ‘code review’ can influence company_ [_culture_](https://hackernoon.com/tagged/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’._

### Code Review Origins

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:

*   Not being aware of a certain coding best-practice
*   Not being aware of all the dependencies between different parts of the code
*   Not fully understanding the original intent of a piece a code thus inadvertently clobbering any planned extensibility
*   Overlooking better ways to build a feature due to tunnel vision resulting from one’s limited coding experience
*   Constantly prioritizing feature deadlines over carefully crafted code, and not making up with code re-factoring thereafter
*   Over-engineering, or pre-maturely optimizing code instead of releasing code often & early, leading to code bloat

_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.

### The Latent Potential of Code Review

_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:

*   **Humility**: The team learns to accept that no one cannot be right all the time, and to err is human, thus they become open to positive criticisms
*   **Open & positive communication**: The team embraces positive criticisms with open arms, as opportunities to learn, which in turn, encourages others to constantly proffer feedback
*   **Alignment towards greater good**: The team understands the _code review_ intent to improve the codebase, and the people working with it, thus always communicating with those at heart. Alignment on intent encourages everyone to tolerate conflicts, and ambiguity in favor of preserving the intent
*   **Respect**: The team learns to respect guidelines, which has everyone’s interest built in, and where the guidelines fall short, everyone work towards respecting the greater good

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.

### Unleashing the Cultural Potential of Code Review

_Code review_, if advocated without supporting mechanisms, usually ends up in one of these extremes:

*   Someone abusing _code review_ as an opportunity to elevate her/his own status and suppressing others, which turns _code review_ into nightmare
*   Everybody playing it safe to preserve a harmonious environment by not being critical of each other, which defeats the purpose of _code review_

To overcome these, _code review_ needs a formal declaration of **intent** (purpose), and a set of **guidelines** to support the intent.

#### **Code Review: 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:

*   Build maintainable and extensible code that is a joy to work with
*   Improve everyone’s coding ability, and understanding of the codebase

#### **Code Review: Guidelines**

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.

**_Coding guidelines_**

These are well-known coding practices accepted by the community, and they focus on [code composition](https://github.com/thoughtbot/guides/tree/master/best-practices) and [code style](https://github.com/thoughtbot/guides/tree/master/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_”

**_Behavioral guidelines_**

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_.

_Situational Criticism_

*   A piece of criticism should be based on a particular piece of code, under a particular circumstance, at a particular instance of time

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.

_Intent-based Criticism_

*   Any piece of criticism must uphold the formal intent of code review

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.

#### Concrete Examples of Code Review (Update 2018–06–02)

Here are a few ‘good’ code review examples that combine both _situational_, and _intent_\-based code review, and a few ‘not good’ examples.

**_Good_**

_Example 1_:

Would it be _easier to understand_ in the future, if we _use a switch statement here_?

*   ‘easier to understand’: Articulate _intent_ of making code easy to understand
*   ‘use a switch statement here’: Make code review _situational_

_Example 2_:

In this part of the code, would using a factory pattern make it possible to handle new use cases in the future?

*   ‘make it possible to handle new use cases’: Articulate _intent_ of making code easy to work with
*   ‘in this part of the code’: Make code review _situational_

**_Not good_**

_Example 1_:

It is good practice to use switch statement instead of multiple ifs.

*   Lacking explanation of _intent_

_Example 2_:

You should use a factory pattern to ensure code can handle new uses cases.

*   Implies that the coder does not understand factory pattern, thus code review does not seem to be _situational_

Note the good code review examples also are often suggestive, inviting discussion, or formatted into question form.

### Data-driven Culture

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_**](https://reculture.us/home/code_review) to keep a pulse on how well the team is adopting _code review_.

### Wrapping Up

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](http://bit.ly/Hackernoon) is how hackers start their afternoons. We’re a part of the [@AMI](http://bit.ly/atAMIatAMI)family. We are now [accepting submissions](http://bit.ly/hackernoonsubmission) and happy to [discuss advertising &sponsorship](mailto:partners@amipublications.com) opportunities.

> To learn more, [read our about page](https://goo.gl/4ofytp), [like/message us on Facebook](http://bit.ly/HackernoonFB), or simply, [tweet/DM @HackerNoon.](https://goo.gl/k7XYbx)

> If you enjoyed this story, we recommend reading our [latest tech stories](http://bit.ly/hackernoonlatestt) and [trending tech stories](https://hackernoon.com/trending). Until next time, don’t take the realities of the world for granted!

Facebook

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Code Review: Beyond Code, Into Company Culture

Too Long; Didn't Read

Company Mentioned

@khor

RELATED STORIES