About the author
Albert Row is a senior software engineer from the San Francisco Bay Area with over 12 years of experience as an individual contributor, technical lead, architect, open-source contributor, and manager.
Albert has been a certified reviewer on PullRequest since December 2019.
Many organizations want to increase the quality of their product but aren’t sure where to start making culture-level changes that will encourage this. Building a culture of constructive criticism is very important, and code reviews are a great venue for constructive feedback.
Most of the examples presented here directly relate to strong feedback loops within development teams on the code review level, but the core principals apply to most other roles and divisions within an organization.
Make it clear that quality is a priority
Emphasize the quality of delivery. Emphasize the importance of maintaining a high-quality bar in the product. Explain that high-quality reviews are part of the quality control process and that the investment in quality reviews is important to your team, your customers, and the business.
This makes members of your team start to think about things like details that could impact things like UX and scalability with a heightened awareness.
Critical reviews take time and are worthy of thanks
When someone gives you a critical code review, say “thank you.” When someone makes recommendations, say thank you. When your code is criticized, say thank you. At any moment when you might feel the urge to be defensive of your work, say thank you. Encouraging constructive feedback starts with recognizing its worth!
Discuss, don’t squabble
It’s important to avoid the defensiveness of your work, but it’s also important to ask questions to make sure you thoroughly understand feedback comments.
Discuss the changes, don’t fight over them. If things start to go south, get on a call between the implementer and the reviewer or meet in person.
It’s easier to see positive intent over a video call than it is in text. Remember that the goal is to create a great product, not to be right. When implementation improves, the whole team wins together.
Ask for a review, not a stamp!
Make it a policy in your organization never to ask for a “stamp” or an “approval” - always ask for a “review.” For developers, never make the assumption that your code is ready for rubber-stamp approval when it heads into code review. This is especially important if you’re in any position of authority - technical lead, very senior individual contributor (IC), management, etc.
The team will both look to you for examples on how to act and be hesitant to give you critical feedback in many cases. As a leader, you need to be especially clear about your own fallibility. Make sure everyone knows that no individual is above the process.
Budget time for reviews
Code reviews take time. A significant amount of time. I generally expect that software developers on my team should spend between 20-35% of their time on code reviews if all reviews are conducted internally. For leads and very senior ICs, the percentage is higher as acting as a teacher is part of the expectation for their role.
If software developers are over-burdened with features and start cutting back time spent on reviews in order to meet aggressive goals, expect quality to suffer accordingly. Make sure incentives are aligned for long-term success.
Don’t let urgency break quality
There will always be pressure to deliver more in less time. There will always be pressure from the business side of the house to move more quickly, to work harder, to deliver faster. It’s best to recognize that the desires of the business side of all organizations are inherently insatiable. By allowing urgency to keep you from maintaining a quality bar, you’re going to lose time in the long run.
The fastest and most direct path to delivery over the long term is, counter-intuitively, maintaining a high-quality bar. Share this perspective at every opportunity. Push back on unreasonable expectations and create the time and space necessary to iterate on work to reach a good quality.
Praise good reviews
When someone gives you a particularly astute code review with good recommendations, compliment them publicly! A message in a public chat channel both broadcasts their good work and points everyone else towards a positive example to work towards.
Encourage reviewers to test code locally
Set an example of posting screenshots when things don’t work locally to demonstrate you’re executing code locally prior to approval. Ask other engineers to do the same.
Ask why visual bugs weren’t seen during code review, or why regressions weren’t caught via tests or clicking around. Add manual testing to your code review checklist or other expectation documents for reviewers.
Challenge “comment-free” reviews
Approvals with no comment other than “LGTM” should be the exception, not the norm. When you see reviews like that, challenge it!
Here’s some language you could use: “While I’m flattered that you trust me this much, may I please have a deeper review? I’m trying to improve as a programmer and would love some constructive feedback from the team on how I can improve the implementation here.”
Invite suggestions for improvement
Ask for feedback on your PRs. Point out areas you’re not sure about. Guide reviewers towards places where your work was rushed. Admit when you’re unsure. Give your reviewers every opportunity to find problems with your code. Request multiple reviews if you can.
Set expectations with a code review checklist
Some awesome ink has been spilled on this topic - including by PullRequest. We have a great article on What Belongs in an Effective Code Review Checklist. If you don’t have a checklist, creating one can help your software team members understand what’s expected as part of every review. Just like with implementation, establishing standards for code reviews helps you improve outcomes.
Share recommendations in code review to the broader team
We write about code reviews… a lot. It’s our bread and butter. You’ll find lots of great content on our blog to share. There are also great articles on this subject from most of the best technology companies in the business. Seek out great content and send it around to your team regularly. Most organizations talk a lot about product and implementation, but topics like quality processes are often neglected. Reading and learning are critical to developing strong habits, and it can help to share great content regularly.
Track your progress
What’s measured gets improved. Track the number of comments per review, the percentage of approvals with no comments, etc. The Github API is a great place to go for this information. It may make sense to build a dashboard using your analytical tool of choice to track review quality over time; you can get set up with PullRequest’s Repository Insights in less than 5 minutes.
Surfacing these numbers to your team will help, and you’ll also be able to identify trends. That will let you pair some of your best reviewers with software developers who might need some help upping their game.
Bring in professionals
If your organization would like to get some external help on code reviews, PullRequest would be more than happy to help. We work with highly experienced professionals from across the industry to deliver great, detailed reviews on your team’s work. Reach out to a team member directly at accounts@pullrequest.com.
Also be sure to check out:
