Some days ago, I had the privilege of sharing this topic with my colleagues at work.

From my personal experience, I figured that most developers don't pay attention to non-technical activities that happen outside our IDEs.

Sometimes, the activities are as little as giving and receiving code reviews and approvals (or rejections).

I gathered my thoughts and here I am, sharing them with you.

Important Notes

• It should be a culture for any engineering team that wants to be healthy. This should be acknowledged.
• It should not be a uni-directional act i.e junior engineers should be confident enough to review senior's codes and vice versa
• It should be known and acknowledged that asking for review doesn’t belittle you. It’s just you admitting to the fact we all make mistakes 💯
• This art has broken several teams that have approached it wrongly. This is because egos were attacked unknowingly
• Communication seems to be the grandfather of all activities. If you can't communicate your intentions well enough, be sure to hurt and be hurt. 😛
• Employ good tools to make PR easier for your team.
• Policies : e.g ensure no one can merge into a branch (e.g master) without at least one approval from a stakeholder.

How do we go about it?

Are you the author? Let's see the few things you should consider to make PR easier on the team.

• Ensure your code is even good and complete enough. No dev wants to review an unfinished work. ✅
• Ignore files that are not necessary to reduce conflicts
• Ensure all your tests (with a good code coverage) are passing. Don't ignore any bit of it. ✅
• Ensure you also have lint checks in place. This depends on what the team has agreed to be the coding styles. There are several code style templates out there. ✅
• Good commit messages. Commit messages should be concise and readable ✅
• Good PR description, if possible attach screenshots. Github Templates can be made use of to ensure everyone follows guidelines ✅
• Request review from all stakeholders of that particular task ✅
• Brace up - you may receive the worst comment in the worst manner ✅

Dear Reviewer, you need to ensure these things too.

• Being asked for a review is not a show of power, intelligence or ego. Don't be an asshole 🆒
• Don’t review under duress… commit enough and reasonable amount of time to the review
• Don’t keep the author waiting for too long especially when it’s critical
• Confirm that all checks and tests are successful.
• Have Empathy. Acknowledge that the author has put in time, effort and money 😄 to produce something that is worth reviewing.
• Be mindful of choice of words - avoid words that will tamper with author’s confidence. Sometimes, adding an emoji does a good job.
• It should not all be about spotting bugs and loopholes. If the author is that bad, he/she won't be on your team. Spot good thoughts, initiatives and leave a thumbs up. 👍🏽
• Be ready to learn from the author. Accept that because it's not done the way you would have done won't make it wrong.
• If the back-and-forth gets too much, try a call to go through the points.
• Suggest edits - Github allows this
• Sometimes, you may just need to pull locally and run things to boost the confidence in the code
• Follow up on the reviews that were made. Don’t assume it’s just a small fix… trust me, I have a personal experience of a small fix that messed up in production. 😢