Conducting reviews
Whenever you conduct code-reviews, remember that there’s another human, just like you, full of emotions and expectations, working towards a common goal to build something great together in a team setting.
That is why it is important to be cognizant of a few pitfalls one might fall into when conducting reviews en masse, part of day-to-day business.
There’s of course, a ton, but here’s just a few of them, along with some strategies I’ve found useful in a team setting that I’ve been employing throughout my career:
Use “What”, not “Why”
Why
was this change done?…
Sure you may feel compelled to genuinely answer this question, but it has now put you in a defensive stance to scramble and gather all your thoughts to make your case and point.
vs
What
was the motivation behind this particular change?…
You’ve now removed the immediate onus that would directly fall on the person this question is being directed to, and instead set up an avenue for healthy discourse, where the goal is to troubleshoot and get to the bottom of the why, and eventually addressing whether said approach is correct or incorrect.
There’s an attitude shift, and you’ve now made it about focusing on collaboration and growth vs meaningless finger-pointing.
Use “We”, not “You”
Can
you
make the change requested for this particular function?
vs
Can
we
make the change requested for this particular function?
This is very similar to the first point, where the lack of tonal information in blank texts written during code-reviews can put the other person on the defensive from the get go. It’s just one word, but it changes everything.
We
makes your involvement known, we
screams “I’m there for you if you need me”, we
is all about collaboration!
Make your non-blocking comments fun/informational
This is just a nice to have and not mandatory.
I usually tend to throw around some fun emojis or facts about nits based on context and situation. It’s the least you can do in exchange for that quick, 1 line code change you are potentially imposing on the other person.
If there are no major blocking comments, SHIP IT
Give the other person trust that they will make the right decisions given your feedback. You will eventually notice the difference 😊
NOTE: A lot of these tips/phrasings can be applied to contexts outside of code-reviews too!
These were some of the tips I wanted to share for now in an attempt to keep things short. If this is helpful, I might do a part 2 with some more tips and actionable scenarios in a future post.
Ciao for now! 👋