How to Deal with an Insufferable Code Reviewer
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.
