Last week, Camille Fournier tweeted this:
Questioning the value of mandatory code review is definitely the most popular underground belief held by senior engineers I know
It launched a discussion about the merits of code review and a bunch of people came forward about their bad experiences. For them, code review had become an arena of power games and a place to demonstrate how smart you are.
I’ve experienced code review as a highly valuable practice and advocated for it, but it’s easy to see how it could go wrong.
Sarah Mei has a talk called The Power of Agile. She speaks about how the power differentials, such as the one between juniors and seniors, cause problems in extreme programming practices such as pair programming. Her key point is that the agile practices do not really address these problems at all.
The same goes for code review as it is commonly practiced. It’s easy for reviewers to bring the process to halt if they want to be gatekeepers or if they are just a bit too pedantic for their own good. They can keep asking for more changes, raise more concerns, and nitpick more.
This happens even when people see each other as equals. It must be worse when you’re a member of a group whose expertise gets constantly questioned due to prejudice. And when you’re a reviewer, there’s the problem of having your review comments ignored.
I’m sure everyone who has extensive experience with code review has sometimes felt frustrated with the feedback they’ve gotten, but if it’s a constant source of frustration, something is wrong.
The junior-senior power differential in code review was always obvious to me – I was introduced to code review as a junior developer – but I’ve only just started to think about the more general power differentials. I hope to come back to this topic with more insight later, but I’m going to leave you with one thought and one recommendation.
Thought: Developing software is collaborative team work. Tool-assisted code review is just one of the tools in the collaboration toolbox, along with pair programming. Reviewing is not an end in itself. The goal is not to produce “perfect” code. The goal is to deliver working software. When reviewing becomes power games, it hinders that goal.
Recommendation: Alex Hill has a great post and a great talk about how to give and receive code reviews gracefully. You should follow her advice. It will make your reviews more egalitarian and more fun.
See also my other posts about code review.