Manager Code Reviews: What 20 years of code reviews have taught me

Many brilliant developers become engineer managers and stop coding. Even worse they stop code reviews too. I believe engineering managers and if possible senior engineering leaders should continue to do code reviews.

🏏 Managers leaving code reviews is like Rahul Dravid retiring to become Indira Nagar ka Gunda instead of mentoring young cricketers. Code reviews are a great mentoring and empathy-building opportunity.

👴 Over the last 20 years, I have had the good fortune to work as an engineering manager, manager of managers, and in the recent past as a senior engineering leader. I have worked with 2-3 person teams, small engineering, and mid-sized teams so far and I have consolidated my learnings here.

Micro teams

🤏 If you have a team of 2-10 engineers, and you are part of the engineering team; your designation doesn't matter. You are probably writing code and in many cases the only reviewer too.

🏗️ Your role here is of a peer reviewer and a senior engineer; you probably focus a lot on functional review. Enough has been written about what to look for while doing these code reviews and I won't go into details.

Small teams

📢 This is where things become interesting. As managers, you may still be doing 1st or 2nd code reviews for your team. You should use code reviews as a medium where you find reasons to appreciate your team members. A lot of people reserve code review comments for recommending changes; I recommend that you also express when a piece of code delights you.

📚 Small teams have to become more serious about code quality and managers can ensure code readability is highlighted. We spend more time reading code than writing it, readable code affects a team's speed positively. If the cognitive overload of a section of code is high (even if your static code analyzer doesn't detect it), you can request a change.

3️⃣ In some cases, managers may also act as peer reviews but largely they are looking at best practices, security, debt, etc. This is where you can start looking at implementing DRY and the rule of three. Get duplicated code refactored in future pull requests.

🧑‍💻As a manager, I probably wrote more code in code review comments than I wrote in IDEs. Write a sample code for how things could be written better for your team. Make code reviews an opportunity to teach your team.

✒️ At the same time, don't always write a solution to all the problems you are highlighting. Sometimes it's okay for you to enumerate the issues and let the team find the best solutions.

Mid-sized teams

👨‍💼 If you lead a mid-sized team or work with multiple engineering managers, you may not get time to review code as part of sprints. I still recommend taking a sample of pull requests (PR) to review them. Choose between feature and refactor PRs.

🖼️ You would often be able to see a bigger picture and the next iterations of your product. While the design stage is the right place for this intervention but even at the coding stage, you can sometimes recommend more future-proof changes.

☎️ Do you see some code where another team/person has already done some good work? Connect the code owner with the other team. They may choose to create a common framework or library with this interaction.

Wrapping up

⏩ Most importantly, if you are super busy, don't insist on the team waiting for your code review comments. Waiting for code to get reviewed is very frustrating and stressful.

📔 Understand why the change is being made. Is it a feature or a refactor? If you can set a culture of adding good commit messages then you have contributed a whole lot already.

🪃 If it's a nitpick, says so in your comment. Your team should know that you are doing the reviews to help them and not for making their life difficult.

💔 Just because you are now a manager doesn't mean your comments can be broad. Helpful comments are specific. Your feedback becomes an order of magnitude more useful when it can specify conditions in the code that will break.

🧲 These code reviews are not for you to prove how good you were as a programmer. The center of attention is the person who requested you to review their code. How can you help them become better programmers in this limited window of opportunity?

🧑‍🔬 Your primary focus is code quality but doesn't stop you from spotting logical issues that even unit tests missed. We all make mistakes, a logical bug doesn't always make someone a bad programmer. Be patient with your team.

🪲 Boundary conditions, malformed inputs, and concurrency issues are some of the common issues I have spotted during code reviews. Concurrency issues, potential deadlocks, and race conditions are especially tricky, if you are reviewing code with these risks, help your team by doubling down on these points.

🧑‍🏫 You are now an engineering manager, but you have probably spent 6-10 years coding every day, making mistakes, discovering patterns, debugging, and designing software. Let your team benefit from your learnings.