Let's talk about code reviews as a manager.
More specifically, I want to talk about the Code Review Review, a.k.a The Meta Code Review. I think every Engineering Manager can benefit from reviewing their team’s code reviews. This post is how and why I do it, and why I think you should do it for your team.
Why you should review Code Reviews
Code reviews and code commenting systems are communication platforms for your team. They are where team dynamics unfold, reveal themselves, and develop. To ignore them is a mistake; a missed opportunity to gain some crucial insights about the people you manage.
I work at InVision, a fully distributed company. Asynchronous communication is the primary way people here on the Maker Schedule get their information. Slack, email, written documentation, Github... the list goes on (and changes often). We are constantly reading and writing on these platforms. And so we’re building a culture through them. That’s why it’s so important that as a manager you are tuned into how your team is using them.
The way your team communicates asynchronously says a lot about its culture.
Code reviews are a place where engineers talk about their craft. It’s where people vent, sometimes directly and sometimes inadvertently. Relationships develop there, squabbles may start there. People connect in those comment fields and communication patterns emerge. Culture is nudged and influenced from these often ignored places of team-building goodness.
How to Meta-Review Code
I usually spend 20-30 minutes a week going through Pull Requests that have come through to and within my team. I’m primarily looking for trends in communication, not reviewing the code itself. Sometimes out of curiosity and for more context I do look deeper into the code, and if that’s helpful for you do it! When I look through a code review, I ask these general questions:
What are people saying in these reviews? Is it feedback about style or structure, or is it about architecture? How much do people even use this platform to communicate?
How are they saying it? Note the tone and communication style. This is where I like to look at what I call “short-typer” and “long-typer” trends. Are answers short and to the point, or are they drawn out. How does that match those individuals’ in-person or verbal communication style? How much care do people put into their responses, and why?
How is the review feedback being received? Who is the recipient and how are they taking this feedback? Is there a lot of back-and-forth? Are people following up within the tool, or outside of it? What are the turnaround times for their follow-up?
The Code Review Review is meant to be a tool for visibility, not an auditing mechanism, for how you team works together. You know your people through regular 1:1s, how does their personality play out in these asynchronous platforms? A Code Review Review is a way to gain insight into the individuals you manage and into how your team forms its culture. So give it a try, and let me know what you think!