7 Code Review Best Practices and Dynamics You Can Identify and Act On: Part 2

in the previous post , we delved into four process dynamics of code reviews that you can identify and act on immediately. now let's turn to the other side of the management coin, which is stamped with the engineers you're leading. in these three dynamics, we'll speak to how you can leverage the code review process to more effectively engage with your team members as human beings.

5: disengaged engineers

just about all of us have encountered disengaged engineers. they tend to stick to their own work, and getting them to engage with the rest of the team requires quite a bit of campaigning.

the thing is, most engineers truly want to be productive, contributing members of their teams. the issue here is that curiosity is the driver of growth for engineers. when we're not learning, we're not excited about our work. and if that sentiment lingers, it can lead us to drift away from our team and our responsibilities. we may even begin looking for other opportunities.

fortunately, engineer disengagement isn't typically a chronic condition. one of the easiest ways to spot that engineers feel disengaged is when they aren't engaging in the code review process.

not only is this lack of participation problematic for the disengaged engineers, but it's also a detriment to the rest of the team. first of all, engineers can feel it when their teammates aren't actively participating in the work at hand. also, reviews are work that simply needs to be handled, so when an engineer is falling short, other members of the team have to pick up the slack.

fortunately, code reviews are a fantastic way to keep engineers engaged, especially during those stretches when their own projects may be a bit of a grind for them. prs can help get them excited about the work going on in the team. a leader's role here is to get those engineers participating in the process, and the first step is to recognize when engineers are acting disengaged so you can intervene to encourage their involvement.

here, you can see the review dynamics for this team over the past 30 days. two engineers at the bottom have hardly engaged in the pr process this month, with only one review each. context matters, of course, and this data provides you an opening to talk to these engineers to understand what's going on to minimize their participation.

perhaps they're slammed with their own work and they just need a bit of a reminder to jump back into code review. or, you might discover something deeper going on: a lack of confidence in contributing with their peers, or discomfort with asking questions of senior members of the team. maybe they feel like no one listens to them anyway, or they need a mentor to help teach them the code review culture in your organization.

whatever the root cause is, your job is to lift up these engineers and encourage them to engage more actively. start with the engineers at the bottom of that list who are the least engaged, and work your way up. we find it helps their participation if you cherry-pick reviews for them at the start-find easier prs for them to complete, or ones that align with their expertise. even aside from approving prs, ask them just to start commenting on more of them.

remember, always, that the simple act of practicing and participating with straightforward code reviews goes a long way toward building up the habit and comfort of engaging.

6: too happy to help

on the absolute opposite side of the scale are the over-engaged engineers. frankly, this may be the toughest dynamic to manage, because these engineers exude all the appearance (and usually the belief) that their work is incredibly helpful.

these engineers are always active in prs. in group emails, they always contribute their comments. they're often the loudest or the most vocal in group conversations. they have input on just about any topic, and they're always willing to share it.

gregarious teammates are often a fantastic part of a team. they can be the spark that ignites interesting and actual conversations. however, in the pr process, they often lose the balance between constructive comments and comment spam. their comments make them feel busy, but the data tells a different story.

it seems counterintuitive that over-communicating in code review be a detriment. but over-commenting comes at the expense of their own deliverables, and it can affect team morale because they're not actually achieving what it's their responsibility to accomplish. as a manager, you may miss that this is happening, because most of what you see appears to be sound engagement. but the teammates know it's going on. they're on the receiving end of that over-engagement, and they're acutely aware of it — they just might be unable to talk to you about it.

which is why it's important for you to spot this dynamic in the data early and manage it proactively.

let's look at the top of this comment activity summary, at the balance of romain's comments to prs submitted. in a two-week period, he made 182 comments on other people's work and submitted just three prs of his own. most other people have a 2:1 or 3:1 ratio. romain's, at 60:1, is clearly an outlier on this team.

there could be reasons for romain's chattiness. for instance, on our team at gitprime, an architect or a team lead might sport that ratio. but romain is neither. absent such a good reason, it's time for a leader to take a look and step in, because this behavior, left unchecked, can drown out the other voices on the team.

it helps to remain aware that over-engaged engineers may have come to believe through learned behavior that commenting in this way allows them to contribute most helpfully to the team. helping others is helpful, right? so as a leader, you need to ensure that you're setting proper expectations and guiding these engineers to correct course.

it's challenging to tell these engineers not to comment so much. it demoralizes them. a more constructive approach is to simply start adding projects to their bucket of work over the next couple sprints. as they naturally feel the pressure of hitting their deliverables, they'll tend to scale back a bit on their commenting activity.

that's when you give them an out.

at that moment, you can let them know, "you clearly have a lot of work on your plate. if that needs to come at the expense of some of the code review you've been doing, that's totally okay."

just giving them that little out is usually all you need to restore balance on the team. that engineer is hitting objectives for the sprint, and the team feels overall happier and more harmonious.

7: better onboarding

we cannot overstate how helpful the pr process can be in ensuring your team is consistently learning from each other. code review is always a chance for cross-pollinating information and expertise between team members. so we'd like to wrap up these seven dynamics by addressing how to use prs to assist with your onboarding program.

after all, a key component of successful engineer onboarding is ensuring both that engineers new to your team are learning the code, as well as learning how to engage meaningfully with their new teammates.

so use the onboarding process to build connections between engineers who will be working together. below, recently hired jeffrey will be working closely alongside alina and maksim, so his manager asked him to focus on reviewing more of their prs. over his first few weeks, jeffrey reviewed two of each of their prs, yet alina submitted a total of 44-and maksim submitted even more.

if you ask your engineers — and particularly recent hires — how things are going, you're bound to get the initial "great" answer. things may be great, and they often are. but sometimes they may be going off track like han solo in a botched princess rescue, bluffing their way by saying, "everything's fine, we're all fine here now, thank you. how are you?"

so you can rely on the data to show you how things are going. perhaps jeffrey's two pr reviews truly went great, but he needs to be doing more. so in the next sprint, his manager can ask him to try participating in at least half of alina's and maksim's work, as well as congratulating him for jumping in on some other engineers' work as well. after all, commenting on multiple people's work will build his rapport with the team over time.

use the data to understand the positives of an engineer's collaboration patterns, as well. you can better understand the quality of their comments in the review process. in jeffrey's case, we can see below that he's getting a ton of traction with alina. she's very responsive. however, maksim is less engaged. his response time is poor, and his review coverage is minuscule. jeffrey may be doing his part to engage, but if maksim is dragging his feet or failing to give jeffrey's comments the attention and respect they warrant, you can use this opportunity to remind him about the importance of bringing the newest team member into the fold.

this is where we really come back to the idea that prs are about so much more than finding bugs. in onboarding, as well as throughout engineers' time with the team, code review is a fantastic way to reinforce cultural values.

by encouraging jeffrey to participate more in the pr process, not only are you encouraging best practices, but you're also empowering him to speak his mind and use his voice. "you were brought onto the team for good reasons," you're saying. "your team wants to hear what you have to contribute."

his participation as a newcomer also reinforces the notion for the established engineers that they need to be open to receiving and accepting feedback. "this is an important part of who you are," you're saying. "and this is an important value for this organization."

in short, prs are one of the best ways not to just talk about your values but to actually live them, every day.

and that's true not just in the onboarding process, but in your day-to-day, too. developing software is no longer about individual engineers cranking out code (if it ever was). it's a team effort. by focusing on these seven dynamics of the code review process and utilizing the data available to you through gitprime, you can improve the value your team gleans from the code review process — and start guiding better engineers and better products as a result.