Shift conversations to the left

In many development teams today, the pull request (PR) has become the cornerstone of code review and quality management. Teams rely on PR reviews to catch mistakes, ensure code quality, and maintain project integrity. However, in my experience, this approach often falls short. Pull requests can be ineffective, frequently going unreviewed or receiving such heavy criticism that the author has to rewrite substantial portions of their code or even start from scratch. To understand why this might be happening, let’s take a look at the history of pull requests and their original purpose.

Good to Know: In DevOps, there is a similar term “shift left” which focuses on moving testing, quality, and performance evaluation early in the development process. Although they might sound similar, that concept applies to a wider range of practices beyond code reviews.

The History of Pull Requests

Pull requests originated in the world of open-source software development. In these projects, maintainers needed a way to manage contributions from strangers on the internet—people they had never met and whose coding skills and intentions they couldn’t necessarily trust. The pull request mechanism allowed maintainers to review code changes before integrating them, ensuring that only quality, secure code made it into the project. This process also enabled asynchronous communication, which is crucial in open-source projects where contributors might be in different time zones and have varying schedules. Discussions about the proposed changes could stretch over days, weeks, or even months until consensus was reached. For open-source projects, this method works well. However, does the same approach make sense for a small, close-knit team in a corporate or startup environment?

Challenging Pull Requests

Why should a team of trusted developers have to rely so heavily on pull requests to ensure code quality? In environments where team members work closely together and know each other’s strengths, the need for mandatory peer reviews for every single change might not be as critical. There are certainly scenarios where peer reviews are necessary, such as for compliance with government regulations. But does every minor change, like updating a README file, really need to go through the same rigorous review process? The insistence on constant peer reviews can sometimes stem from a lack of trust within the team. Instead of trusting that our colleagues are doing their best work, we impose a safety net of mandatory reviews. This can create a bottleneck in the development process and can lead to frustration and inefficiency.

A better way

Instead of waiting until the end to review code changes, teams should shift conversations to the left. This means discussing how to approach solving problems as a team before the coding even begins. Seek feedback early and often to ensure alignment and to catch potential issues before they become significant problems. Early conversations can help mitigate the risk of receiving poor or overly critical feedback late in the process. When you discuss your approach with your team upfront, you build a shared understanding and trust. By the time you are ready to open a pull request, your team is already familiar with your work and the reasoning behind it, reducing the chances of major rewrites or conflicts.

Looking for ways to make this happen? here are my suggestions:

• Schedule regular meetings to discuss upcoming tasks and their implementation strategies.
• Improve psychological safety so that team members feel comfortable sharing their ideas and feedback early.
• Keep a record of agreed-upon approaches to avoid confusion later in the development process
• Do not shy away from pair programming no matter what level you are at.

Conclusion

In conclusion, while pull request reviews can be valuable, they should be optional rather than mandatory. We should prioritise a team culture where discussing approaches and seeking early feedback is the norm. This way, by the time a pull request is opened, it’s more of a formality than a critical review point. By prioritizing conversation over pull requests, teams can improve trust, efficiency, and overall code quality.