Code reviews must change!

1. Ask your devs WHY they aren't doing PRs

Here are some improvements that worked for me, but they may not be relevant for you.

Schedule PR time. Project stakeholders must understand PRs take time, they affect sprint scheduling. Sometimes it takes 2 days for a PR if it's a massive change.

Tag reviewers for PR, ensure they receive notifications HOW THEY WANT TO RECEIVE THEM. Some people like Slack, some like email, some people check GitHub. Personally, my GitHub emails would go into a folder and never be seen. But I checked the website itself.

PR owners should remind reviewers after 1-2 days. Every day that passes increases project risk.

Thank people when they review a PR promptly or particularly well. "Thanks for catching that bug!". "Thanks for reviewing!" etc.

Personally, I would usually review PRs every day, after lunch. Encourage people to set these habits.

if you're having this problem too much, it could be that the developers are too siloed, and need to do more swarming..

Siloing is the habit where each developer is constantly working on a completely different thing from everyone else. For them to do a PR is so much harder because 1) They have no context or understanding for what's happening. 2) They are less motivated because they are busy working on their own tasks. (and their own tasks are what actually affect their performance review)

Swarming means getting multiple devs working on the same general area at once. Having those devs do each other's PRs is much easier since 1) They probably already know what the code will look like because (hopefully) they've already had a discussion about how to implement it. 2) They are more motivated to get the code completed because it's their project too.

Hi Mikaal, I've been trying to solve this problem for a while.

I've built coderbuds.com to help with code reviews with AI.

I also integrate with Slack for updates.

I'll look into PR templates too.

If you want any more features let me know

Elliot

Easy answer: tie CR's to performance reviews. Keep in mind Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.” so I wouldn't be firing or handing out bonuses from code review stats but keep an eye on it and discuss with the team. Also keep in mind more CR's doesnt mean better CR's. Instead of monitoring individual performance I have heard of teams implementing an internal "SLA" for code reviews of 2 hours.

I'd also encourage making CR's as painless as possible via;

• solid CI/CD pipeline
• ideally make breaking the pipeline basically impossible through things like precommit hooks, automated testing to block breaking changes, code coverage levels etc.
• if the pipeline is broken it becomes priority #1.
• require a CR to have a detailed description of the change, a link to the work ticket etc.

People reporting they wait a day or more for a CR blow my mind.. Don't over index on CR's, bugs will always get through but automate to cover as much as possible and with good technical leadership and practices you'll be on the right track

Code reviews are hard. Even after doing hundreds of them, I still think that's the underlying truth.

For the tools side of things, I created https://www.indiehackers.com/product/readyforreview-2 (GitLab only), which helps for non-trivial reviews. Still, it doesn't take away the burden of having to understand

1. the previous implementation
2. the bug/feature request
3. the code changes that someone else did.

Despite this, I think code reviews are indispensable for building software professionally.

You could try mob programming? Haven't tried this myself yet, at least not in a structured way, but want to. Not sure if this would work well remote though.

• Plan a day per week to do PR's. Possibly make it a team event, make the reviewer sit with the contributor.
• Alternatively, hand out the role of reviewer to those best equipped and most interested in it and make it a dedicated role; with the time allowance to fully take care of the PR's.

I did PRs and Code Reviews for the first time at a company in 2020. I really disliked it. Here's an alternative I like:
https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/