The Distressed Code Review

The Problem

I had an experience with a company I worked with years ago. Their code-review process was broken. It took weeks or more to get a review completed.

It was all done in the name of writing "good code," but the result was less than effective.

What I started to realize was that the process, for this company had become a way that the developers could push back against a restrictive environment.

Details

As a developer, we could be writing extremely problematic code and finding coworkers irksome for simply pointing that out.

At the other end of the spectrum, the code could be fine but a toxic culture in the organization creates endless nitpicking. In environments like this, the code review becomes an adversarial activity, many times not about code quality.

What should our goals be?

• Determine what is causing the stress?
• Determine what should the desired outcome be?

Code review processes vary so widely from team to team, so let's examine what the goals should be ...

The Code Review

Considering the subject of code review itself (the code), there are two conceptual levels at play.

A code review has important human ramifications. People learn and share knowledge through the review process. And they use it to prevent the kind of defects that result in frustration for the team. Developers get emotionally invested in their creations (we own the code we write).

A good code review process helps with code quality and helps developers learn. It is the most effective defect prevention method. This put a good code review ahead of even automated unit tests.

Often, the closest a developer gets to actual organizational power comes during interviews and code reviews. Decent human beings handle this well, looking to mentor and teach. Unfortunately, this power can also be abused.

Check and Improve

The first strategy for dealing with a distressing code review is the simplest.

• Is the review genuinely helpful (if poorly delivered)?
• And, is there room for improvement?

This may be a case where a developer can, "grin and bear it." Work, being a four-letter word, will result in exposure to some annoying people. Sometimes, they just happen to be reviewing code.

Take the feedback seriously. Internalizing it. And see what happens. As developers, we get better at writing software. The hope is that these reviews become less annoying over time.

Ask For Change

If the "distressing" reviews continue, there comes a time when we need to create an inflection point. Be direct and ask for different behavior, avoiding the objectionable things. If their behavior changes, the problem is solved, even if there was some stress getting there.

If not, you have learned something and have information to act upon. I personally think life is too short to spend dealing with unpleasant people.

Dont Involve Management

Its tempting to find a referee. The idea is that they will intervene and referee.

Engineer Less Interaction

Do not involve management directly about interpersonal differences. This does not mean we cannot involve them indirectly. This method can take some time, so figure out how to manage until this change is implemented.

Figure out how to work on something else or be somewhere else. Get creative at getting distance from the code reviewer.

You can certainly involve management in these discussions. In fact, youll have to. Dont cite anything negative as your motivator ... leave that out. Instead, offer to work on a project that others dont want, or ask to transfer because of your interest in your new, requested project.

Most of the employees couldn't directly approach the reviewer, couldn't changed teams, and could not go over their head to speak with management.

They left the company. I could clearly see that this was one factor of many that attributed to the high turnover rate.

The Solution

With the company I described at the beginning of the article, getting code reviewed was a "distressing" process.

In my case, I approached the reviewers that were causing the issues and had deeper theoretical discussions on code. This process created a connection that allowed me to smooth out parts of the review process.

It wasn't a straight-forward solution and I wouldn't always recommend this approach, but it did work at the time.