Strategies for Dealing with an Insufferable Code Reviewer

This post originally appeared on my blog about a year ago, in response to a reader question.

Time for another installment of reader question Monday.  Today, I'm going to answer a short and sweet question about how to deal with an "irksome" code reviewer.  It's both simple, and fairly open ended, making it a good candidate for a blog post.

How do you deal with peer code review and irksome coworkers? Any trick?

Okay, first things first.  This could cover a lot of situations.

Theoretically, someone could be writing extremely problematic code and finding coworkers "irksome" simply for pointing that out.  And, at the complete other end of the spectrum, the code may be fine but a toxic culture creates endless nitpicking.

In environments like this, the code review becomes an adversarial activity, as much about political games as about code quality.

So you must introspect and also think in terms of your goals.  What is it that's irking you, exactly, and what is the desired outcome?

I'll frame the post roughly in terms of goals, and my advice for achieving them.  Really, that's the only way to do it, since code review processes vary so widely from team to team.

A Bit of Perspective on Code Reviews and Code Reviewers

Before going into any advice, let's consider the subject of code review itself.  There are two conceptual levels at play.

Obvious Level: A Practice with Demonstrable Benefit

A well-conducted code review process helps with code quality and it helps developers learn.  In his book Code Complete, Steve McConnell cited a study that found "formal code inspection" to be the most effective defect prevention method.

This put it ahead of even automated unit tests in the study.

But, beyond that, code review has important human ramifications as well.  People learn and share knowledge through this process.

And they use it to prevent the kind of defects that result in frustration for the team: rework, embarrassment and even a need to come in on weekends.  People with a stake in the codebase get emotionally invested.

Subtle Level: Small Kings in Small Kingdoms

There's also another, more subtle element at play, however.

I talk extensively about these terms in my book, Developer Hegemony, but you can read a brief primer here.  Software developers (to my endless irritation) are pragmatists (line-level laborers) with almost no actual influence in the corporate world.

When you participate in the so-called "technical track," you typically never have people reporting to you, earning only developmental titles that include things like "senior," "tech lead," and "architect."

So often, the only simulacrum developers get of actual organizational power comes during interviews and code reviews.  Decent human beings handle this well, looking to mentor and teach.

But there are a lot of less-than-decent human beings out there, who relish these opportunities to wield what little power they have.  The phrase, "a little man with a little power" comes to mind.

1. First Line of Defense: Check Yourself and Improve

The first strategy for dealing with an annoying code reviewer is the easiest and most straightforward.  Is the feedback genuinely helpful, if poorly delivered?  And do you have plenty of room for improvement?

If that's the case, and if you're serious about improving your chops, then you can just kind of grin and bear it.  Signing up to work anywhere will result in exposure to some annoying people.  These just happen to review your code.

So start by taking the feedback, seriously internalizing it, and seeing what happens.

You'll get better at writing software (which generally makes you more marketable and your job more satisfying).  And the hope is that these annoying reviewers become less annoying as they develop a grudging respect for you over the course of time.

2. You Could Always Ask Them To Behave Differently

Maybe it's not a simple matter of you having room for improvement.  Perhaps it's just stylistic or philosophical differences that the annoying reviewers continually harp on.

Or maybe they continue to behave this way even once you incorporate their feedback, endlessly shifting the goal posts.  Who knows, maybe they just like to argue.

Whatever the case, it's time to create an inflection point.  Be direct and ask them to behave differently, avoiding the things you find objectionable.

They'll react in one of two ways:

1. They might take your feedback and modify their own behavior.  If so, problem solved, even if not always perfectly.
2. But, if not, you now have a data point.  If you come to someone with a civil appeal and it's rebuffed, you've learned something about the culture.

For instance, if you say, "hey, I don't mind the feedback, but can you not be so insulting," and they counter by saying something like, "it's not my job to be nice," you probably have a king of the hill situation.  These code reviewers subconsciously like to pretend that they're Gregory House or Linus Torvalds but without the achievement.

If that's the case, you should probably do something.  If you're anything like me, you probably think life is too short to spend your life dealing with unpleasant people.

3. Don't Involve Management

It's tempting to use management as a referee, particularly since the typical corporation models itself as a parent with you as the child.  The idea is that they'll intervene and referee.

But that's not actually advantageous for you.  Your manager might do this and get the self-important code reviewer off your back, but, even if this works, it costs you political capital.

Most likely, your manager is some kind of non-technical idealist, or perhaps an opportunist.  In either case, you're making yourself a problem when you do this.

At the risk of painting with a really broad brush, the hostile code reviewer is almost certainly a journeyman idealist (a corporate pragmatist obsessed with the programmer meritocracy delusion) or an expert beginner.

This will often be a loud, opinionated, relatively long-tenured person that a manager simultaneously finds annoying, but also depends on.  Usually, management has a sort of codependent, Stockholm Syndrome relationship with these people, viewing them as a lot more indispensable than they truly are.

So when you march in and present your interpersonal problems to them, management will probably sympathize.  But they'll also feel a bit uneasy at the prospect of upsetting a productive prima donna.

And they'll feel a little annoyed with you (especially the non-technical ones) for getting into petty arguments over unimportant technical mumbo-jumbo.  (You and your antagonist may not view your differences this way, but management definitely does.)

4. Engineer Less Interaction with this Code Reviewer

I've told you not to involve management, and I mean that.  Don't involve them directly about interpersonal differences.  But that doesn't mean you can't involve them indirectly.

Figure out how to work on something else or be somewhere else.  It's too situationally dependent for me to offer a specific play by play, but get creative at distancing yourself from the annoying code reviewer.

• Can you work on a different project, or maybe even just a different part of your current project?
• Can you request code reviews from different people?
• What about transferring teams?

You have options.

You can certainly involve management in these discussions.  In fact, you'll have to.  But don't cite spats with people as your motivator -- leave that out.

Instead, offer to work on a project that others don't want, or ask to transfer because of your interest in your new, requested project.  Figure out a pretext to get out of Dodge.

If your management is savvy, they'll actually understand your real motivation without you ever needing to cite it.  But this way, you don't spend any political capital.

You're not complaining and you're proposing a solution to your problem, rather than asking them to solve it for you.

5. Make It Worse for Them than They Make It for You

Now we're getting kind of far down the options list, but direct warfare is an arrow in your quiver.

There are basically two types of people that make insufferable code reviewers:

1. First, you have the "let's argue loudly about everything but no hard feelings" types
2. And then you have "I'm always right" types.

I'll give you a quick approach for each of these.  First, the "let's argue loudly" type.

Code reviewer: Your code is completely wrong!  Use tabs instead of spaces -- review failed.

You: You're actually wrong, but I'll change it because you're the senior dev.

Code reviewer:  I'm wrong?!  Wrong?!  No I'm not!  Here are 800 reasons that blah blah blah.

You: Relax, I said I'd change it.  You've been here a long time, so Bob's your uncle.

Code Reviewer: Why I never, ratcha-fratcha blah, blah, blah!

You: ¯\_(ツ)_/¯

Remain calm, and even a little amused through these exchanges.  This personality type hates this sort of thing.

You never give them the satisfaction of being right, but you very agreeably point out that they're in charge because they've hung around the company a long time, so they don't need to be right.  They get 0 satisfaction out of this and it makes them nuclear, so they might start to simply leave you alone.

With the "I have to be right," expert beginner type, you take a different approach.

Study up on all of their claims, all of their code, and their whole approach.  Study diligently, as you look for each and everything they've ever done wrong in code in their lives.

Stockpile this information as if you were in a cold war arms race.  Make it your job to prove this person wrong about each and everything he ever says, if possible.

Once you've got this in place, ruthlessly pick him apart at your next code review.  Bring books, websites, case studies, and whitepapers.  Cite industry expert quotes about how wrong he is.  Embarrass him.

Your goal is to become a software porcupine.  If he's going to hurt you, you're going to make sure it sticks in his craw, infects him, and makes him miserable.  He'll leave you alone to look for easier prey.

6. If All Else Fails, Quit

If all else fails, you can always quit.  Or, honestly, maybe even if all else doesn't fail.

As I've said, life is too short to waste in situations that make you miserable.  And this holds doubly true for software developers.  Demand for our labor is off the charts, so it's not as though you lack options.

Don't let people convince you that being "passionate" is an excuse to treat you poorly, and don't settle for shops populated by tiny kings in tiny kingdoms.  You have far too many options for that.

And, writing software should be fun.  So if it's keeping you up nights or sapping your enjoyment out of your career, engineer a change of scenery.

It always makes people nervous to jump, but I can never recall anyone saying, "wow, I left, but I sure wish I'd stayed in that lower salaried job, working with those awful people."

If you'd like to ask a reader question, you can do so at the "ask me" page.