The Art of Giving and Receiving Code Reviews

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. 😢

© 2023 O.A