The Culture Is in the Code Review

Someone once told me that a company’s culture isn’t defined by your HR department or your C-suite - it’s defined by how we show up and treat each other every day. It’s built in the small, daily interactions that demonstrate the sort of behaviors that are and are not rewarded when working at $dayjob. For engineering teams, the question then becomes how do we play our part in this? What does it mean to influence our team culture, and what are tangible ways we can make a positive impact on it? For those of us working on and leading teams of software engineers, we have a uniquely powerful lever here: the oft-controversial code review. Yet most of us only think about them as quality gates, missing their potential as culture-building tools.

There is a lot of great information out there on how to prepare your code for review, and how to be a good reviewer. This advice is often focused on how to avoid creating a toxic experience around the code review, which is absolutely the right place to start - If your team is still at this stage, I’d recommend checking out a few of those articles before going any further. However, for those of us ready to take it the next level I’ve come across a few other ways to turn code reviews from just “not toxic” to “positive influence” for your team. The moment I truly understood the power of this approach was during a seemingly routine code change, and it’s shaped the way I’ve approached code reviews ever since.

A Lightbulb Moment #

It’d only been a few months since I’d started at a new company. I’d joined as a Senior Software Engineer, which was a miracle in my eyes as I wasn’t sure I’d ever make it back to engineering after being a Product Manager for the past 2 years. My new team was small, but it was quickly clear to me that it consisted of some of the best engineers I had worked with up to this point. They’d been on the team for years already and their depth of knowledge around not only the product we were building, but the technology we were using to build it was inspiring. I was eager to prove that they had made the right choice, and that I belonged on this team alongside them.

They’d hired me to take over one of the team’s oldest codebases. It was written in Python, which luckily I had a good amount of experience with, and I’d started to find my rhythm; contributing increasingly more meaningful changes with each PR. It was time for me to take on my first major release and I was looking forward to it, but doing so would require not only changes in the codebase I’d been getting more comfortable with in the last few months, but also another codebase our team had - one that was even older and more complex. To make matters worse, while I was comfortable with Python this other service was written in Node.js, which I barely knew. The pressure was on.

Only hours had passed since I’d submitted the pull request when the email came in; I had received my first review and it was from the most senior engineer on our team (he was Sr. Staff by title). I opened the link from the email and the imposter syndrome immediately set in. This review came with over a dozen comments. “Oh no”, I thought, “I must have royally screwed this up”. Steeling myself for the worst, I scrolled down and read the first comment:

praise: I really like the name you chose for this function, it makes it very clear what it’s responsible for and made the code easier to read.

I did a double take. Was this code review comment… praising my work? I’d been around the block by this point in my career, but this was the first time I’d seen anyone use a code review as a vessel for encouragement. I’ve got to say - it felt good! Really good! Scrolling through the rest of the review, not everything was so rosy of course: I didn’t use an existing testing pattern they had in place, and had a few nits called out, but several other comments also called out positive aspects of the code I’d contributed. In that moment, I realized I’d discovered something powerful.

Why This Matters #

Now let’s talk about why this was so impactful. I believe taking the time to praise good choices in the code you are reviewing has 2 positive consequences that both ultimately lead to one outcome - a better team culture.

The first consequence of including encouragement in your code reviews, is that it just feels good to be on the receiving end. Depending on your organization and how deep in the stack your product is, software engineering can feel like a thankless job at times. As humans (even the software engineering kind) we need encouragement to maintain motivation about the work we do. By providing positive feedback in your code review you get an honest opportunity to say, “Hey, I see your work and I appreciate it” without making the praise about yourself. As an added benefit - while praise doesn’t pay the bills, promotions do. Peer feedback in code reviews are a great way to leave a public trail of the good work someone else is doing. If you think the work they did was especially noteworthy, leave your encouraging feedback and then Slack their manager with a link to it.

The second consequence of including encouragement in your code reviews, is that it reinforces good choices across the team. If the only thing we ever tell our team is what we don’t like, we leave ambiguity about the things we do like and should do more of. We avoid our worst, but never take full advantage of our best. This of course can be a great nudge for a junior engineer who is still figuring out what “good code” looks like, but for an experienced team this is an opportunity for an even bigger impact! When someone refactors for readability even though it wasn’t in the requirements, or when they add thoughtful error handling that goes beyond the minimum specs - these are the kinds of behaviors that separate good engineers from great ones, but they’ll go unrecognized in reviews that are focused solely on eliminating problems. By leaning into positive feedback, you are implicitly saying, “Hey, I saw you went above and beyond on <the_thing_they_did_right>, and on this team we celebrate that!”. This action impacts two audiences. The first is the engineer whose code you are reviewing, who now knows “This is something that is valued so much that we go out of our way to recognize it”. The second, is any other reviewer of that code who also sees your comment and learns the same thing. As engineering teams, code reviews are one of our most organic ways to develop the culture around how we work together. Don’t only use this tool to set a culture around the things you avoid, use it as a tool to set the culture around the things you really want to excel at as well.

Implementing This With Your Team #

Now let’s get a bit more practical with a couple tips on how to implement this with your team. The first tip, is to make it your own. If adding a praise: prefix to your comment isn’t your style, then don’t do it! Personally I prefer to clarify that my comment is positive feedback by using a 👏 or 🎉 emoji instead, so comments I leave look more like:

👏: Great test coverage here, you’re catching edge cases I hadn’t even considered. Well done!

You don’t have to follow that pattern either if that doesn’t feel natural. The point is to find the way of adding positive feedback to your PR that feels natural to you. That also means you don’t need a prefix at all if you don’t want one. I find it’s a helpful pattern for making async PR feedback especially clear to the reader, but the point here is providing the positive feedback, not the specific format that you write it in.

My second tip, is don’t abuse this. I know some of you are rolling your eyes right now, thinking that fluffy praises are breathless and that in this economy no one has time to write feel-good messages in all their code reviews. I absolutely hear you. Here’s the number 1 rule I have for anyone considering taking this advice:

Don’t give encouragement you don’t actually mean

It’s easy to read this article and then force a praise into every code review from now on. But that quickly removes the authenticity of the act, and invokes a similar principle to “once everything is important, nothing is”. I don’t recommend leaving praise in every review. Some code changes are small, straightforward, or just don’t require anything notable to execute. Others need a lot of coaching, and nobody needs another “feedback sandwich” in their life. But if you do see something praise-worthy, that was an example of someone really well demonstrating a behavior that you want to see more of on your team - be generous with the encouragement in your review. It goes a long way in shaping the culture and impact of your team over the long-term.

Thanks for reading! Here’s three things to consider when applying this to your own career growth.

1. Look back at code reviews you’ve given within the last month. Are there any spots where the engineer did something positive that you could’ve called out? (It’s not too late to let them know in a private Slack message.)
2. While this advice can be used on the fly (that’s how I started), it’s even more impactful when you first define which behaviors are worth encouraging on your team. There are a million ways to write software “correctly”, but which of those aspects are most important to your team? Think about the engineers who got promoted recently or who you’d choose to be on your team 10 out of 10 times. What specific behaviors did they demonstrate that you want to see more of? This is what you should be encouraging.
3. How might your reputation as someone who builds others up through code reviews impact your own career trajectory? Whether you’re considering Staff+ roles, management positions, or technical leadership - they all require influence through others rather than just individual achievement.