The Solution to Games in Code Reviews

                                                                               Photo by Marsha Reid on Unsplash

I used to be curious as to why developers suddenly got curious during code review.

“I’m curious as to why you aren’t handling null-pointer errors here”

“I’m curious if you’ll get a rounding error here”

“I’m curious what happens if this value is ever empty”

And on it goes.

I’ll tell you the truth. I’m no longer curious as I’ve worked out what is going on.

Curiosity Killed The Truth

These types of questions look innocent. Most of the time, they’re anything but.

Veiling change requests as a question that you’re curious about is anything but helpful. It’s passive-aggression at best.

Passive-Aggressive Questions Waste Everyone’s Time

So, you might have a bad day. Imagine a pull request where (for example) a method doesn’t handle null inputs properly. It’s a problem and needs to be fixed.

“I’m curious what happens if the parameter is null?”

So, if you’re curious you don’t know what happens. Am I to believe this is not a change request and something that can be ignored? Or are you not expecting an answer to the question and a code change to be made?

By employing such tactics, you need the original developer to play detective. How is this supposed to play with new or junior software developers? Are you documenting your little psychological games so outsiders can understand? Is this part of your onboarding program?

I want to make this real. You’re excluding people. That’s the opposite of teamwork. This isn’t collaboration, it’s the opposite of that.

What To Do

Yes, actionable ideas.

This isn’t about removing genuine questions from code reviews. It’s vague leading questions that avoid giving action feedback that is a problem.

If you need a change, say so.

“Add a null check here”

We can go further. When you have a real question, prefix the question with the word (get this) question.

“Question: Can you explain how this method handles edge cases for empty strings?”

When you have a nitpick suggestion, write nit.

“Nit: Consider using a different naming convention for clarity.”

Make comments that are clear, actional and respectful of everyone’s time. Make passive-aggressive questioning a thing of the past. Please.

Conclusion

We work with developers who have different levels of experience. People might come from different cultures, and they might be non-native speakers of the host language. A software engineer might be neuro-diverse. A developer seeking a code review might be having a bad day.

The last anyone needs in their day is a cryptic comment to decode, let alone one laced with emotion or written with the intention of making the writer feel “powerful”.

Instead of playing power games, play the game of “improve the code”. You’ll all come out winners in that particular game.