Empathetic Code Reviews

By Lars Klevan

BetterUp’s employee culture is anchored on our shared values of Courage, Craftsmanship, Playfulness, Grit, Empathy and Zest. As an engineering team, we want to bring innovative products to life, which requires us to move quickly while maintaining our high standards for security, code quality, and user experience.

As a code reviewer, it can feel like there’s a tension between “holding the line” of quality and our desire to move fast, but by applying our value of Empathy, we can do both and do so in a way that demonstrates our mutual respect and compassion.

Meeting me where I am

As a reviewer, we can get our Empathy flowing by imagining ourselves in the shoes of the person who authored the code. A good question to start with is “Where is the author currently on their learning curve on the BetterUp codebase?“ This question helps us focus our feedback on what would be most helpful.

For example, with a highly experienced coworker, my main goal is to provide a second pair of eyes, just to make sure that there’s not something they didn’t think about and to focus on the most critical code review points of security and system stability. Assuming that we have a strong rapport I’m comfortable leaving brief suggestions or questions like, “Does this work if there’s an existing record?”

For an engineer who is new to the codebase, I want to be treating the whole code review as primarily a learning experience. For that reason I usually conduct my first few code reviews with a new employee as a synchronous meeting. That way we can take the time to talk through key decisions, talk about alternatives, and most importantly to use the review as an opportunity to learn about our model, guidelines, and conventions.

What is driving the change?

Another good question to ask is, “What is the context that went into this change?” This can be easy to answer if the change is part of a project where you’re heavily involved. That might not always be true. So, we want to ask ourselves, “Is this part of a high-profile project?” “What would happen if I request a fundamental change?”

In a situation where a change is urgent, we can steer our review by taking the mindset of, “Do I see a major problem with this change?” In a situation where the change is less urgent, we have the luxury to look for more incremental improvements, like, “This class is becoming pretty complex, should we consider a refactor?“ By taking the context into account, we can avoid a situation where an engineer is under pressure to deliver and being derailed by less essential feedback.

What should I do with this feedback?

As a code author, it can sometimes be hard to know what to do with the feedback you get in a code review. “Do I have to address this feedback, or is this something to keep in mind for the future?” “What do I do if I get conflicting suggestions?” As a reviewer, you can make the code author’s life much easier by answering these questions in advance.

At BetterUp, we often use a convention of tags to hint at our intentions as a reviewer. #optional can be used for feedback that is meant to spur thought but not require action. #minor is a good way to soften nitpicks. We use #namingishard to acknowledge that choosing names for things in software is tricky, but important. And my favorite is #followup, to indicate that this shouldn’t block the release, but it would be nice to track an issue with a ticket.

Reviewing in partnership

Combining these practices, we hopefully change the role of reviewer from being a gatekeeper to being a partner and teacher. By tailoring our feedback to the ramp-up stage of the author, we can unlock speed and learning. By understanding and accepting the context of the change, we can move quickly when we need to, and take opportunities to improve. By being intentional with how we intend the feedback to be addressed, we can ensure our team can be blocked only when it’s really needed, and we can create the spirit of partnership that lets us do amazing things.

About the Author

Lars joined BetterUp in 2016 as a Senior Full Stack Engineer. He lives in Minneapolis with his spouse and two elementary-age daughters. When he’s not out walking around the lakes he can be found playing tabletop games or eating nachos.