A bad commit at Auth0 has repercussions. The company handles authentication and authorization for thousands of applications and companies, from Atlassian to Mazda to News Corp. A commit that degrades performance or sacrifices security could bring down entire enterprise organizations or lead to massive data breaches.

“It is critical and has a daisy-chain effect of affecting others. I think this affects the importance of code review,” Umut Benzer, tech lead on the IAM Authorization team at Auth0, told us. “At Auth0, everyone takes it seriously.”

We talked to Umut about how code review works at a remote company when the stakes are so high. He has recently written about how Auth0 conducts effective code reviews, going into the nuts and bolts of their processes. Here, he wanted to talk more about what he sees as the most important part of effective code review—communication—and how to build it and hire for it in a remote culture.

Remove opinions from code review through better communication and data

“[In one of my previous companies], we had discussions, and sometimes we’d forever discuss one small thing,” Umut told us. “Sometimes it even led to a whole rewrite, wasting people’s time. So I had that experience, but nothing at Auth0.”

This is what can happen when code review becomes a battleground because of disagreements or too much emotion in a PR. Everyone should take code review seriously. But when opinions become contentious, it stops code review being, as Umut put it in his Auth0 article, “fun.”

Though Auth0 is a tech-heavy, engineering-centric company, the culture is one of collegiality, communication, and soft skills.

“One of the things we embrace on my team right now is to document rules about what you can complain about or what you are expected to say in code review,” Umut said.

There are no overall code review guidelines for the whole company, though Umut hopes to turn his own blog post on the subject into a guide for the company. Instead, there are company-wide engineering practices, and each team decides how to implement code review.

Code format is one area that is low-priority in the IAM Authorization team code review. Code formatting is done automatically and enforced by automation. If a code review is only about coding style, then you can add a suggestion, but it is up to the code owner to decide whether to make the change. “That is your way of doing it, but you are not doing it; someone else is doing the PR. So you can only pick that up as a suggestion,” Umut told us.

In this way, the discussion is cut out even before you start. Code reviews are quicker and less contentious, and they concentrate on the more important parts of the code, which, for Auth0, are performance and security.

The entire dynamic is different when a review finds issues with either of these two aspects of the code. Auth0 processes 100,000,000 logins every day, so inefficient calls, caching, or algorithms have significant downstream effects.

“We are trying to be very cautious about the performance of the code that we are writing because we get high traffic, so it’s sort of a big deal,” Umut said. When a reviewer highlights code performance issues, the team turns to collect data to objectively determine the best solution.

“Sometimes we get some suggestions that our code could be better, in terms of performance. In this case, usually you’ll take comparison and the faster wins,” Umut said. “Everyone agrees to this, and the code owner doesn’t create a problem, because it’s all about the performance.”

In this way, the data overrides the code owner. If performance tests suggest a better way, the better way is taken. But if the suggestion is stylistic, then the code owner has a choice of whether to incorporate the suggestion or not. Then, the team can discuss whether they want to adopt and document the style wholesale in the next team meeting. The code gets better through code review and documentation.

Hiring for communication skills makes for better code review and better code

When a team relies so heavily on good communication to perform well, hiring for communication skills is integral. Auth0 has a different hiring process than most—one that allows the team to assess “soft skills” such as communication, ways of handling code review in a team setting, as well as their underlying engineering ability.

The candidate is given a project to work on for one week. But instead of going away and working on it alone, the candidate is integrated into the team for that week.

• They are asked to join a single-channel Slack with all team members.
• They are given the project in that channel. Importantly, it isn’t overly detailed, which leaves room for interpretation and questions from the candidate.
• They do research and communicate in the channel about the project. Any questions are answered by the team.
• The candidate writes code and submits PRs. Some communication is via code review; other communication is done through the Slack channel.

“It is a simulation of being a part of the team, not just code review, the whole package. It is important because you learn about the communication skills and other soft skills of the candidate, and the code review is a part of it,” Umut told us. “How does this candidate handle conflict if we say something totally opposite and sometimes wrong? What is the discussion like?”

This team benefits from seeing the candidate’s communication skills in a real-world environment and understanding if the candidate is someone who will fit the team’s code review and communication style by concentrating on larger issues and, as Umut puts it, “not struggling with small stuff that is not really important.”

Clarity of communication is critical in remote company code review

Remote companies are in focus right now. Auth0 has always been remote (it was cofounded in Bellevue, Washington, and Buenos Aires) and the company has written a lot about remote work.

How does code review work in a remote culture? “I’ve never heard anyone complaining about code review being hard due to remote, and I don’t think it is as well,” Umut said.

Code review can work better in remote work because the culture puts such an emphasis on communication. “You need to understand it alone without an explanation and without any pressure, where you focus on the code and nothing but the code,” Umut told us. This means the code owner has to be explicit about what they mean in code comments and in the description of the PR.

“I don’t think this is special to remote culture. This has to be that way every time, but when you are remote, it is much more important,” Umut said.

Of course, code review in a remote culture also has downsides. If you and your reviewer have time-zone differences, you might have to wait an entire day to get a review or to get an answer to a question. But that can be mitigated through better up-front communication in Slack and stand-ups. If you feel that someone is taking too long with a code review, you note it and bring it to the meeting—you don’t start an argument in the review.

On the reviewer side, making time for review in a remote culture is the same as in-office. One “hack” Umut had at a previous co-located job was to work in code reviews after a natural work break so that it didn’t impede the flow of your own work.

“After every break, someone going to coffee, they get back and before starting their routine, they check for pending code review,” Umut told us. “We tried to not interrupt people just to have the code review, but took advantage of the interruption to do code review. It was pretty nice.”

Conclusion

It can be hard not to take bad reviews personally. That is why emphasizing communication skills is so important in a tech team. One reviewer can drag down an entire team by nitpicking and imposing small details on every PR.

Effective teams, like those at Auth0, see code review differently. They are there for the mission critical stuff. They are there to make sure the code in the PR works as best it can. You do that by moving opinions to other channels of communication and making the reviews about data and performance.

This works only if you build those skills in your team. Great code can’t be written without great communication, so the more you build that in your team, the better your code will be.