Ideally, on trusted teams, reviewing a change set is best done by someone synchronously (not asynchronously) who is intimately familiar with the feature domain, the code base and has been involved throughout the code creation process. I am describing a pair in a pair programming approach. This provides a continuous review process between two people in synchronous fashion before it is committed to trunk. In some scenarios eg open source projects, asynchronous code reviews are more appropriate. However, the vast majority of software teams do not work in this context, and crucially would gain far more from pair programming and synchronous working patterns.

Preparing your code for peer review is a crucial step. Start by ensuring your code is clean, well-organized, and follows the project's coding standards. This includes proper formatting, naming conventions, and commenting. Comments should be clear and concise, explaining the rationale behind complex sections of code. It's also important to test your code thoroughly before the review to catch any obvious bugs. Providing a brief overview or documentation of the changes you've made can be incredibly helpful for reviewers. This preparation not only makes the review process more efficient but also demonstrates your professionalism and respect for your peers' time.

In a world of trunk based development, pair programming and continuous deployment to production: a git push means a deployment to your real end users. Placing the onus on the original authors of the code, scaling up process with size/risk of the change, is one of the most effective ways to reduce waste in a team.

Giving feedback respectfully is vital in peer code reviews. Approach the review process with a constructive and collaborative mindset. When suggesting improvements or pointing out issues, be specific and focus on the code, not the coder. Use phrases like 'I suggest...' or 'You might consider...' to convey your points in a supportive, non-confrontational manner. Remember to also highlight what is done well in addition to what could be improved. This balanced approach fosters a positive learning environment and encourages open, productive dialogue. Respectful feedback not only helps in refining the code but also strengthens team relationships and boosts overall morale.

Learning from the peer code review process is essential for personal and professional growth. Be open to the feedback you receive, viewing it as an opportunity to improve your coding skills. Pay attention to recurring themes in the feedback, as they can indicate areas where you might need further improvement or study. Additionally, when reviewing others' code, observe and learn from their coding styles, techniques, and problem-solving methods. This two-way learning process enhances your understanding of best practices and broadens your technical knowledge. Embrace the code review process not just as a task, but as a continuous learning journey, integral to becoming a more skilled and versatile developer.

Code reviews and pull requests are not a safe default, and in some cases contribute to holistically decreased code quality. This is because the baseline cost of change, even for a small change, has a fixed cost of a PR review. In my experience, this leads to people not always making small refactorings *as soon as they see them*. Removing the process overhead for these tiny changes can quickly add up to a big impact on holistic code quality (even things like renaming variables and methods). This is because people are unwilling to invest in the total cost of change (including the process overhead of code reviews and a pull request), for small changes.

Effective peer code review is a valuable practice that can enhance code quality and facilitate knowledge sharing within a development team. Here are some best practices for conducting peer code reviews: 1. Set Clear Objectives 2. Keep Reviews Small 3. Choose the Right Reviewers 4. Automate What You Can 5. Provide Context 6. Encourage Collaboration 7. Be Respectful and Constructive 8. Use a Checklist 9. Rotate Reviewers 10. Set Time Limits 11. Follow Up 12. Learn from the Process