Advice for getting faster code reviews?
At my company, I've experienced receiving a lot slower code reviews than usual. I think this is because I'm on a Platform team but each individual member is very specialized to their focus area. We're encouraged to tag a specific person (and I've been assigned a specific person for my code reviews) as well as the team for broader visibility.
However, I'm often stuck waiting 24-48 hours before receiving anything and always need to ping the person that has been assigned to my reviews. It felt pretty awkward needing to do that all the time so I brought it to my manager. My manager essentially let me know we don't have a good process around code reviews yet and are still figuring it out, and it could be a good opportunity for me to bring a good process to the table. He recommends pinging people in the meantime and to not view it as bothering. I am open to doing that, but still wondering if there is a better way.
I have 2 questions:
- What could be a good way to propose a code review process to my team, especially given each individual is specialized to their own area within Platform?
- In the meantime, what would be a good way to get faster code reviews from my assigned person who is intended to be reviewing them?
![Mid-Level Software Engineer [SDE 2] at Amazon company logo](/_next/image/?url=https%3A%2F%2Ffirebasestorage.googleapis.com%2Fv0%2Fb%2Ftech-career-growth.appspot.com%2Fo%2Fcompany_logos%252Famazon_logo.jpg%3Falt%3Dmedia%26token%3Dff5f2302-08be-43bc-b7b1-d381ba508d99&w=48&q=75){kind=logo}
Discussion
(3 comments)- 12 years agoMeta, Pinterest, Kosei
This definitely feels like a high-impact opportunity, to change the culture + behavior around code review! I left some thoughts about reviewing code in domains you're unfamiliar with in this answer (and Alex has some great thoughts here)
- I agree that pinging people for code review after 36-48 hours feels broken. That can really be a drag on individual + team productivity. I'm not sure how clearly defined the various areas are, but could you have a primary and secondary specialty area for each person. In general, having just 1 person who can review code for a project feels really dangerous to me -- there should be at least 2-3 people, and if that's not there, the team should prioritize training up more people.
- (I'd have this conversation in a meeting rather than in a code review.)
- To make it easier for the person reviewing your code, give them ample context. This manifests in a few ways:
- Brief them ahead of time with what you're doing: here's the project, timeline, and why it's important. Here's when you can expect to write a lot of the code for it. Share relevant docs/architecture diagrams with them.
- Add sufficient details in the summary + test plan for each change you submit. You want it to be clear to someone, even without much context, why the change is needed and why it's safe. Also see the full length talk we gave about code review here.
Finally, could you bring more awareness to the number of code reviews that are done by each person? ("What gets measured get done") Maybe a dashboard which shows who has the highest number of code reviews, and send out an email each week (or ask your manager to) celebrating the top 2-3 people.
- I agree that pinging people for code review after 36-48 hours feels broken. That can really be a drag on individual + team productivity. I'm not sure how clearly defined the various areas are, but could you have a primary and secondary specialty area for each person. In general, having just 1 person who can review code for a project feels really dangerous to me -- there should be at least 2-3 people, and if that's not there, the team should prioritize training up more people.
- 1
2 years agoSenior SWE + Researcher, 23andMeI’ve found posting a link to the PR in a forum like Slack can help. If there’s a team channel, posting there can still allow others to read at their leisure. Definitely agree with what Rahul said about providing context.
- 02 years agoSenior Software Engineer [OP]Series C Startup
Thanks for the answer, Rahul. To get more available reviewers, trying to encourage us to train a bit more in our non-specialized areas is a good idea. On your second, point, I definitely am doing my best there in terms of summary, providing screenshots of the UI changes, making small PRs, etc. To be honest my impression is that people aren't even opening it up which is the big problem. Even though I have someone that my team agreed will be the primary reviewer I am needing to ping him for each review. This is the case even for 5-10 line reviews
