How To Find Success With Code Reviews

Developers tend to like code reviews — when they’re done right. But getting code reviews right can be tricky, in large part because it’s such a human process.

Adrienne Braganza Tacke is a software engineer and author of “Looks Good to Me: Actionable Advice for Constructive Code Review.” In this episode of The New Stack Makers, she spoke with me about how to ensure code review processes go smoothly.

“There’s a lot of human factors in it that could make it go wrong — and a lot of teams will just say, forget it, we’re just not going to do it,” Braganza Tacke said. “It doesn’t bring the team the value that it should be bringing, because of all these other negative things that could surround it.”

Three Challenges to Successful Code Review

To ensure success with code reviews, there are three challenges Braganza Tacke said teams need to address head-on.

The first is any potential ambiguity in the process. It’s important to have a clear process about what the code will achieve and any stylistic preferences before the code is written — and well before the code review process. But it’s also important for both the submitter and the reviewer to be precise during the code review process.

“Being ambiguous leads to a lot of problems,” she said. “You go through so much more back and forth because you’re not aligned on the code or what it is.”

Ambiguity can lead not just to rework, but rework done incorrectly because the reviewer wasn’t clear on what needed to be fixed. That’s why it’s important, she said, to be as explicit as possible when performing code reviews.

The second potential pitfall is subjectivity, she said. Code reviewers will sometimes engage in subjective reviews about code preferences rather than focusing on objective reviews about whether the code did what it set out to do.

“Why are you stating something is wrong? Can you back it up? Is there a better way to do something? Certainly bring that up in the code review, but don’t say it just because you think it’s the better way — describe or justify why it is a better way to do something,” Braganza Tacke said.

“Coming from an objective background, rather than a subjective background, especially in the review process … will go so far in terms of keeping the team dynamics much better on your team and during code reviews.”

The third challenge is letting go of ego during code review. That can be difficult, because people tend to be attached to their code, but it’s important for both the submitter and reviewer to check their egos at the door.

“I have experienced it myself, where there’s somebody who thinks they’re the greatest developer ever, and they use the code review as a way to put other developers down,” she said. “Or every single review that they are asked to do, they use it as an opportunity to rewrite the code and say this is a better way to do it … instead of starting a conversation or really working with the team.”

Programmers: Be Your Own First Reviewer

Braganza Tacke learned early on that her own ego could be a barrier to better code. She worked at a company that did not have a formal code review process, but code was sent to quality assurance for review after completion. She admitted she had to do an ego check on herself and how she approached that process.

“I was the developer. They were the quality assurance person who is just testing something. If they found something wrong, maybe they were wrong,” she said. “That was a very big ego check for myself that, no, I did not write perfect code every single time. No, when they did find something, that doesn’t mean that it was something small or insignificant.”

She also had to learn that just because she finished the code, it didn’t mean that she had finished her work.  She began to realize that the first code review should be with herself.

“If you are able to do your own review, and you can do it as many times as you need to, that’s another chance for you to improve the actual code that you finally send up to the reviewer,” Braganza Tacke said. “Anything that we can do to make our code better and to do as many self-checks as possible before the code review will actually make the code review more productive because then the reviewer is not wasting time on those smaller stakes issues.”

Done right, code reviews can be a way to improve code, mentor new programmers and ensure the whole team is familiar with and vested in the code, she said.

“The knowledge transfer and the knowledge sharing that can happen in code reviews is really, really important, and that levels up the skill and the knowledge of the entire team,” she said.

Tune into this episode of Makers to learn more about how to succeed with code reviews.