How Do You Guys Do Your PRs?

Pull Requests (PRs) are a crucial part of the software development process, serving as a bridge between writing code and merging it into the main branch. Recently, I’ve had the opportunity to welcome some junior developers to my team, and their approach to PRs has made me reflect on how we handle this essential process.

In the past, when reviewing my colleagues’ PRs, the process was relatively straightforward. I would read through the code, look for potential improvements, and provide feedback. However, with the inclusion of junior developers, I find myself taking a more hands-on approach; I often check out their branches locally to ensure that everything works as intended, fulfills the requirements outlined in the Product Backlog Item (PBI), and adheres to coding standards. This has left me wondering: is this the norm for senior developers, or is there a more efficient way to handle PRs?

The Importance of Clear Criteria

One of the first points raised in the comments on my original post was the significance of having clear acceptance criteria for tickets. Acceptance criteria define the conditions that a product or feature must meet to be accepted by stakeholders. By having well-defined criteria, junior developers have a clearer understanding of what is expected from their code submissions.

Additionally, it’s essential for the code to include tests that verify it meets these acceptance criteria. Automated tests play a vital role in ensuring that the code is not only functional but also maintains the integrity of the existing codebase. When CI/CD pipelines are set up correctly, they can automatically catch issues related to code quality, coding standards, and testing failures. This automation can significantly reduce the burden on senior developers during the PR review process.

A Shift in Responsibility

Another insightful point raised was the idea that code reviews should not solely rest on the shoulders of senior developers. While it’s understandable to have a senior sign off on a PR, it should be a collective responsibility. Encouraging junior developers to review each other’s code can provide them with valuable learning opportunities. They can pick up ideas, patterns, and best practices that they can apply in their own work.

Promoting a culture of shared responsibility in code reviews can help foster a sense of ownership and collaboration within the team. Everyone, regardless of their experience level, can contribute to the improvement of the codebase and learn from one another in the process.

The Minimal Expectations for PRs

As one commenter aptly pointed out, the minimal expectation should be that developers verify their code before opening a PR. Whether through manual testing, automated tests, or a combination of both, ensuring that the code works as intended is fundamental. The PR review should focus on the quality and maintainability of the code rather than acting as a build server.

A sanity check during the review process can help confirm that the code addresses the problem described in the ticket. This means that while it is important to review the code for potential improvements, it is equally essential to trust that the developer has done the necessary groundwork to ensure functionality.

Conclusion

Navigating the PR process with junior developers requires a delicate balance of guidance and autonomy. By establishing clear acceptance criteria, fostering a culture of shared responsibility, and maintaining minimal expectations for code verification, we can improve the efficiency of our PR reviews.

Ultimately, the goal is to create a collaborative environment where junior developers feel supported while also encouraging them to take ownership of their work. With the right practices in place, we can ensure that our PR process not only maintains code quality but also serves as a valuable learning experience for all team members.

How do you handle PRs in your team? Share your experiences and insights in the comments below!