The Art of Code Reviews: Building Better Teams

# The Art of Code Reviews: Building Better Teams

Picture this: It's 3 PM on a Tuesday, and you're staring at a pull request that's been sitting in your queue for two days. The author is a junior developer who's clearly put their heart into this feature. But as you scroll through the code, you can't help but notice several issues that need addressing.

How do you provide feedback that helps them grow without crushing their confidence? How do you catch bugs while building a stronger team?

After years of conducting code reviews at Spotify, GoJek, and other companies, I've learned that the way we review code can make or break team dynamics. It's not just about finding bugs—it's about building better humans.

## The Human Side of Code Reviews

Let me share a story that changed how I think about code reviews.

Early in my career at Spotify, I was reviewing a pull request from a talented junior developer. The code worked, but it wasn't following our established patterns. My first instinct was to point out every deviation from our style guide. But then I remembered something my mentor had told me: "You're not just reviewing code—you're mentoring a person."

Instead of a laundry list of "fix this, fix that," I started with: "Great work on implementing this feature! I can see you've really thought through the edge cases. I have a few suggestions that might make this even better..."

The difference was night and day. The developer was engaged, asked thoughtful questions, and we ended up having a great discussion about architecture patterns. That experience taught me that code reviews are conversations, not corrections.

## The IKEA Effect: Why We Get Defensive

Here's something fascinating I learned from [Philipp Hauer's work on code review psychology](https://phauer.com/2018/code-review-guidelines/): The IKEA effect.

When you assemble IKEA furniture yourself, you value it 63% more than if someone else had assembled it. The same thing happens with code. We place disproportionate value on code we've written, making it harder to accept feedback.

I've seen this play out countless times. A developer spends days perfecting a solution, only to receive feedback that suggests a different approach. Their first reaction? Defensiveness. "But my way works!" they think.

The key insight? You are not your code. Criticism of your code is not criticism of you as a human being. Once you internalize this, code reviews become opportunities for growth rather than personal attacks.

## The Three Filters: Is It True, Necessary, and Kind?

Before leaving any comment, I ask myself three questions inspired by April Wensel's compassionate code review approach:

Is it True?

Wrong: "You should use getter and setter. This code is wrong."

Is it true? This assumes an absolute truth that rarely exists. Avoid words like "right," "wrong," and "should." Often, you're just expressing your opinion.

Right: "In this case, I would recommend using getter and setter because it improves encapsulation. What do you think?"

Is it Necessary?

Wrong: "There's a space missing here."

Is it necessary? I believe there are more important things to discuss than missing spaces. Nagging tends to annoy the author and reduces their openness to feedback.

Right: "Let's focus on the core logic. The spacing is fine."

Is it Kind?

Wrong: "This factory is badly over-engineered. The trivial solution is to just use the constructor."

Is it kind? Absolutely not! This statement is shaming and makes the author feel stupid.

Right: "This factory feels complicated to me. Have you considered using a constructor instead? It might be simpler for this use case."

## The Art of I-Messages

One of the most powerful techniques I've learned is using I-messages instead of you-messages.

Wrong: "You are writing cryptic code."
Right: "It's hard for me to grasp what's going on in this code."

Why does this work? Because it's hard to argue against someone's personal feelings. When you say "I find this confusing," the author can't respond with "No, you don't!" They can only ask "What would make it clearer for you?"

## The OIR Rule: Observation, Impact, Request

When giving feedback, I follow the OIR pattern:

Observation: "This method has 100 lines."
Impact: "This makes it hard for me to grasp the essential logic of this method."
Request: "I suggest extracting the low-level details into subroutines with expressive names."

This approach is non-confrontational and focuses on the impact rather than the person.

## Don't Jump in Front of Every Train

Here's a mistake I made early in my career: I felt like I had to comment on every single line of code. The result? Authors became defensive and stopped listening to my feedback.

Now I focus on the issues that matter most. A missing space? Not worth mentioning. A potential security vulnerability? Absolutely worth discussing.

The goal isn't to be a pedant—it's to help create better software and stronger teams.

## The Power of Questions

Instead of making statements, ask questions. This encourages discussion and learning.

Wrong: "This variable should be named 'userId'."
Right: "What do you think about using 'userId' for this variable? It might be clearer than 'id'."

Questions invite collaboration. Statements invite resistance.

## Accepting Different Solutions

One of the hardest lessons I've learned is that there are often multiple valid solutions to the same problem. Just because I would approach something differently doesn't mean the author's approach is wrong.

Right: "I would do it this way, but your solution is also fine. What made you choose this approach?"

This opens up a conversation about trade-offs and helps everyone learn.

## The Author's Mindset: Be Humble

For authors, the key is maintaining a humble mindset. To err is human—everybody makes mistakes. This doesn't mean you should code carelessly, but it does mean you should accept that you'll make mistakes and that's okay.

Remember: You are not your code. Programming is just a skill that improves with training, and that improvement never stops.

## Creating a Culture of Learning

The best code reviews I've been part of felt like learning sessions. The author and reviewer were exchanging knowledge, not just catching bugs.

At Spotify, we had a practice where senior developers would explain the "why" behind their suggestions. Instead of just saying "extract this method," they'd explain how it improves testability or makes the code more maintainable.

This approach turned code reviews into mentorship opportunities that benefited everyone involved.

## The Three Pillars of Effective Code Reviews

Based on my experience, effective code reviews rest on three pillars:

1. Respect: Treat the author as a valued team member, not someone who needs to be corrected
2. Learning: Use reviews as opportunities to share knowledge and grow together
3. Collaboration: Work together to create the best possible solution

## A Personal Story: The Review That Changed Everything

Let me share a story that illustrates the power of compassionate code reviews.

I was reviewing a pull request from a developer who had been struggling with confidence. The code had several issues, but instead of pointing them out directly, I started with what they had done well.

"Great job handling the error cases! I can see you've really thought through the edge scenarios. I have a few suggestions that might make this even more robust..."

The result? They were engaged, asked thoughtful questions, and we ended up having a great discussion about error handling patterns. More importantly, their confidence grew, and they started contributing more actively to team discussions.

That experience taught me that code reviews aren't just about code—they're about people.

## The Ripple Effect

When you conduct code reviews with empathy and respect, something beautiful happens: it creates a ripple effect. Team members start treating each other with more kindness. They become more open to feedback. They start learning from each other.

I've seen teams transform from competitive environments where people were afraid to make mistakes into collaborative spaces where everyone is focused on building better software together.

## Wrapping Up: The Art of Human Code Reviews

Code reviews are an art that requires practice, empathy, and a focus on human connection. They're not just about finding bugs—they're about building better teams, sharing knowledge, and creating a culture where everyone can grow.

The next time you're reviewing code, remember: you're not just looking at lines of code. You're working with a human being who has put their time, effort, and creativity into solving a problem. Treat them with the respect and kindness they deserve.

Ask yourself: Is this feedback true, necessary, and kind? Will it help this person grow? Will it make our team stronger?

If the answer is yes to all three, then you're not just reviewing code—you're building a better future for your team.

---

What's your experience with code reviews? Have you had a review that changed how you think about feedback? I'd love to hear your stories and continue this conversation about building better teams through better code reviews.