Code Reviews and Culture

I just finished reading Creativity, Inc. a couple of weeks ago, and the lessons that Ed Catmull shares around the requirements for creating an organizational culture that fosters risk-taking and innovation have been rolling around in my head ever since. He argues that in order to make creativity possible, organizational leaders need to create safety for people to fail — because running up to the edge of the unknown sometimes means that we accidentally fall over it. When people feel safe to take risks and put themselves and their work out on display to get great feedback, when they know that their jobs and their self-respect aren’t on the table every moment at work, it unleashes a huge amount of creative energy that simply isn’t unleashed in other environments.

With that perspective in the back of my mind, it’s been particularly thought-provoking to participate in conversations at work recently around peer code reviews — why and how we should be doing them, what benefits do we hope to gain from them that we don’t get currently. Code reviews (CRs) are a crucial place where organizational culture plays out in day-to-day behaviors in software companies, and done poorly, they can be detrimental to organizational well-being.

I want to be absolutely clear: Code reviews have a ton of benefits and I believe wholeheartedly that they are a critical part of the software development process. CRs enable knowledge sharing about the software design and code within the team and outside the team. They cast a light of clarity around requirements and how developers have interpreted and implemented those requirements. CRs help teams find and fix defects while the impact of those defects is small and the cost to fix them is also small. They are a crucial way that teams iterate towards readability, maintainability, consistency, and elegance in their code. CRs are one crucial feedback mechanism to help less experienced developers grow their skills, to help more experienced developers share their hard-learned experience, and leaders to guide and coach their teams. My concerns here are not that we should or shouldn’t be doing code reviews in our teams, but instead that we need to unpack and really look hard at how we do code reviews in our teams.

Code reviews are often horrific experiences for people battling impostor syndrome and for people who are inexperienced and still learning the craft of making software, and play a huge role in driving away people who don’t interact well in competitive and confrontational environments. This isn’t a gendered issue — there are plenty of men who struggle with this but who feel that they can’t even talk about it. Poor CR etiquette definitely affects underrepresented people harder than others, because they’re playing the game with fewer privilege cards and end up “out” first when there aren’t clear and fair rules about how conflict and disagreements in perspective get resolved. This is because CRs are ultimately one key place where power and rank and the struggle for influence and dominance manifest in teams, where team culture and company culture is made and renewed every day.

My favorite way to understand culture is Johanna Rothman’s definition that culture is “How people treat each other, what people can discuss, and what you reward.” Kellan Elliot-McCrea talked about culture in a blog post announcing his departure from Etsy as “what you do, not what you say. It starts at the top. It affects everything. You have a choice about the culture you promote, not about the culture you have.” I think a lot of software teams are promoting a toxic team culture through their code review practices, possibly unintentionally, because the leaders on those teams have not explicitly set expectations and demonstrated good CR etiquette. These behaviors and this culture are learned and transmitted to others — and they can be changed.

Poking around the internet, plenty of organizations have guidelines for how to run code reviews, but most of them focus only on the technical aspects of doing CRs. They provide checklists for what classes of errors or style issues for reviewers to look for when performing CRs. They encourage thoroughness and reviewing small change sets. They encourage the code submitter to acquire a thick skin and recognize that “you are not your code.” There isn’t always clear guidance for how to perform a CR as a reviewer while keeping in mind that there is a human being on the other side of that CR. To be sure, there are plenty of developers who do have good CR etiquette, but I’ve found they have often learned it in the school of hard knocks by being on the receiving end of bad and hurtful CR behavior and intentionally choosing for themselves to be better.

This problem — of not having clear guidelines and expectations for behavior — isn’t limited only to code reviews. I’m intrigued by the proliferation of conference codes of conduct all over the tech industry as a way to intentionally and explicitly lay out the ground rules for conference etiquette, and I think this might be a solution for code review etiquette as well. If software teams and organizations were to have a clearly documented code of conduct for CRs, I think it would go a long way towards making code review behavior explicit instead of implicit, would help teams to openly discuss how their culture and values play out in CRs, and would help create safety in CR conversations. Ultimately, if done well, I think it would help teams move more towards a culture of creativity and openness and innovation.

I’m still drafting and refining what a CR code of conduct might look like for my team, and how it might be adopted by the rest of the organization. I’ll happily share my results with anybody who is interested in taking this approach on their team, and if there are teams out there who already have a CR CoC, I’d appreciate a link. In the meantime, I hope this sparks a conversation in the wider tech scene on CR etiquette and how we can all own our piece in making CR practices candid and kind, honest and empathetic, beneficial to all participants, and a constructive part of our team cultures.