Pull Requests and the Secret Handshake List: Enhancing Collaboration on Dev Teams

Pull Requests, also known as PRs, are a very popular method used to submit code to be reviewed before release. PR reviews - where the team gives feedback on the work of other software developers - are great tools to improve code quality, facilitate knowledge sharing, and maintain consistency. Being a good team player during PR reviews is very important for a productive and positive environment among developers.

The "Rules" for Reviewers

1. Be humble and respectful.
   I cannot emphasize this enough: admit when you're unsure and let go of your ego.
2. Be consistent.
   Apply the same rules every time to others and to yourself.
3. Call out good things.
   It is essential to call out good things and be positive because this solidifies the team's trust and improves relationships.
4. Be explicit and concise.
   Clearly communicate your feedback/idea/suggestion. Nobody wants to see a long message of why you think differently.
5. Provide examples.
   When you have a suggestion, the best practice is to be clear and add links/code examples. Be proactive with your feedback.
6. Make the effort to understand the author(s) perspective:
   Take your time to read the code, try to understand why the author wrote the code that way, don't be greedy, and remember to trust your team members.
7. Move your deep thoughts and opinions offline.
   Nobody wants to deal with philosophical discussions over the comments, most of these discussions can be handled offline.
8. Branch out.
   Make sure the code you are reviewing is actually working, pull the branch out, run the code, and do some tests.
9. Suggestions are always better than requests.
   Remember, the code isn't yours. To respect the author’s time and perspective, it is always better to suggest than request.
10. Learn:
    PRs are a very good source of knowledge, what better way to learn and get paid at the same time? 😆.
11. Not everything is about you.
    Because someone does something different than you would, does not mean it is wrong. Read that again.

The "Rules" for Authors

1. Be grateful.
   At the end of the day, we all have the same goal, so we need to be grateful for our team member's time, comments, and suggestions. “Thank you” and “Please” are more than welcome.
2. Explain yourself the best.
   Provide context for your code, don't take anything for granted. Spending a few more minutes creating an excellent description will save everybody's time.
3. Include media.
   “A picture is worth a thousand words”, adding media to your PRs will make them easier for the reviewer to understand. I strongly recommend LICEcap, check it out!
4. Give credit.
   If there are more people involved, don't take the all credit for yourself, share the “Sweetheart Shampoo” with all the persons involved.
5. Merge as soon as possible.
   Not talked very often, but MERGE!, avoid code conflicts, and save yourself the extra work.
6. Never rush, please be patient.
   We all learn this the hard way when we make a mistake or we create a bug. So the last thing we want is to make another mistake and create another bug. Take your time to fix your own mistakes. “Measure twice, cut once”.
7. Comment your own code.
   Adding comments on your own PRs, yes, you can explain in advance and save some time.
8. Manage your feelings.
   Comments on your code and change requests are not personal attacks on you, reviewers are doing their best, just like you. At the end of the day, they are meant to make the code better.

Simple, right?

Believe it or not, PRs are a great opportunity to keep/enhance a positive development environment and are essential to maintaining team morale and productivity.

This light highlights the importance of maintaining respectful and constructive communication during PR reviews. What else would you add to the list? Let us know!

Thank you for reading 😄.