What do you do if your code review process is hurting rather than helping?

You cannot fix a problem until you identify the problem. Any suggestion about automation, culture, guidelines, and so forth are absolutely secondary to figuring out why the code review process is hurting. Also, WHO it is hurting. Is the issue that feedback is being given courteously and professionally but has to be repeated over and over because the recipient never acts on or learns from it? Is it that the feedback is "let's all sit around the table and bash the obvious idiocy of Bob, no offense, but really, this was totally boneheaded, and Bob, I want you to just take away from this that we all want you to do better rather than get offended." People are so quick to try and adopt a best practice or go with a tool before root cause.

Work with a good requirements tool and a robust process. To assess the impact of a single code module, link it to requirements. Then, not only the coding persona is in charge but also function and product owners. Bind review processes to teams that are interconnected to features. Also, try to abstract the process with KPIs and OKRs. It will distribute responsability fairly to teams, not to single people.

Begin by thoroughly assessing your existing code review process to identify specific pain points. Gather feedback from all team members involved to understand their experiences and concerns. Are reviews taking too long? Is the feedback too vague or overly critical? Identifying these issues is the first step towards improvement.

Simplify the code review process by defining clear, concise guidelines and expectations. Ensure that reviews focus on critical aspects like code quality, security, and functionality, rather than nitpicking minor issues. Automating repetitive checks with tools like linters or CI/CD pipelines can reduce the workload on reviewers and allow them to focus on more substantive issues.

the review process should be simplified, clear guidelines should be defined. In my opinion, the focus should be on security-critical aspects, then the readability and functionality of the code should be taken into account, here you could use clean code and adhere to principles such as SOLID. The code reviews should also never become personal, it ‘must’ always be neutral and factual about errors, if possible already with ideas how it should be and the most important thing, you should also justify this factually, because the person who wrote the code may not have known better and can become better at his job through the code reviews, which again benefits the future process because reviews are done faster and last but not least the company.

Implementing reasonable timeframes for code reviews can help keep the process efficient and prevent bottlenecks. Set expectations for how long reviewers should take to review code and for how quickly authors should address feedback. This can help maintain momentum in the development process and prevent delays.

Automate code reviews using tools like linters, formatters, and static analyzers to catch issues automatically. Utilize built-in code review tools within pull requests. Encourage reviewers to give specific, constructive feedback, fostering a culture of mutual learning and growth.

Linting, automated formatting, and using tools like rubocop (in Ruby) to enforce best practices before the code is even submitted should be standard practice regardless of whether or not nitpicking formatting is a time sink. There's a certain cognitive load in trying to manage formatting rules and follow the flow of the problem anyone is trying to solve.

Cultivate a positive, constructive culture around code reviews. Encourage reviewers to provide specific, actionable feedback and to highlight what’s done well, not just what needs improvement. This can help create a more supportive environment that promotes learning and growth, rather than one that feels adversarial or discouraging.

Improve collaboration by facilitating more direct communication between reviewers and authors. This can be through pairing sessions, face-to-face discussions, or video calls, which can help clarify feedback and resolve issues more quickly. Clear, open communication can make the review process more effective and less frustrating for everyone involved.

Continuously monitor the effectiveness of your code review process and be open to making iterative improvements. Regularly solicit feedback from your team and be willing to adjust your approach based on their input. This ongoing refinement ensures that the code review process evolves to meet the team’s needs and contributes positively to the development workflow.

Keep Merge Requests/Pull Requests as concise as they can be. It's much less intimidating for peers to review smaller chunks of code (which may help get reviews done faster) + it is easier for peers to do the review process more justice, when they pay closer attention to the changes.