• Peer reviews keep changes flowing through the deployment pipeline and out to production
  
• Peer reviews share knowledge between engineers
  
• Peer review participation and quality are part of your annual performance evaluation
  
• Peer review participation and quality is a core part of the process of obtaining deployment rights (permission to merge code without a peer review, or to be the sole review on other folks’ code)
  

 

Tips & Tricks

• Add yourself as a reviewer: when picking up a PR for review, add yourself – that ensures we don’t have two people accidentally reviewing the same PR
  
• Perform a functional test: keep an eye out for edge cases and details the developer may have missed
  
• Perform a code review: look for potential inefficiencies, logic errors, or code that could be better organized
  
• Be open to learning: we all have different skillsets, and seeing someone else’s code can help you find ways to improve your own in the future
  
• Be responsive with re-reviews: if you noted some concerns and the developer updates the PR, re-review the same week
  

 

Your code = your responsibility

Keeping pull requests flowing through the pipe is something we’re all responsible for.  The best way to ensure your code is merged in a timely manner is to be proactive.  Here are some tips for when you’re the one submitting a PR: 

• Review your own code: immediately after putting in the pull request, skim the diff – you’d be surprised how often you’ll catch small errors that would have held up your PR
  
• Ensure your PRs are well-documented: include the goal of the change, a link to the Zoho task, and a detailed test plan; anyone should be able to pick up your PR and start reviewing without needing to talk to you
  
• Seek out peer reviews: don’t just wait for someone to come along - especially if your code has sat for weeks without review
  
• Be responsive with changes: if a reviewer notes any concerns, address them promptly; remember, a task isn’t done until the code is merged
  

 

How do I make time?

I know we’re all very busy, so here are some comments on how peer reviews fit into your weekly schedule: 

• If you feel like you’re not going to be able to complete peer reviews by Tuesday on your scheduled      week due to other work, please try to find a substitute the week before to swap shifts with
  
• If you find yourself unexpectedly slammed early in the week, speak up ASAP to find a substitute or someone to split the time with
  
• If you consistently feel like taking time to review PRs will jeopardize your other scheduled work, speak up so we can adjust your schedule to ensure that’s not the case
  
• You can still review code if it’s not your assigned week – it’s a great way to fill a half hour between meetings
  

Questions or comments?

If you have any questions on the above, please don’t hesitate to ask, and if you have any tips or recommendations from your own PR processes that might be useful, feel free to share.  It’s a team effort, and every bit helps!