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