Code review — mindset

Long intro

Let’s start with something intriguing: In a code review, the least important thing (most of the time) is the code.

If you still are reading this and you haven’t closed the page already, I want to share with you my opinion on code reviews. Like any other programming activity, you might need some creativity, and you need to be “in the mood” to do this. You can’t give a professional and high-quality result if you are not in the mood to do “that thing”. It’s like being a song composer: you can’t write lyrics without being in the mood to do it, are do it with a high quality.

3 Years ago, I wrote an article on why I am doing code reviews and a checklist that you can use when doing it. I think my article was a little bit more focused on new teams, with juniors and mid-developers. Now, I will try to write this towards the mindset that you need to have while doing it.

Why?

We are doing it to ensure quality, whatever that is. Quality in software is like God in religions. If you ask 5 software creators (whatever role), what quality is, you will get at least 6 different answers (because at least one will change his mind while telling you what this thing is).
In reality, the most important thing in 99% of the cases code readability is the most important thing. Yeah, a strategy pattern is way better than having a switch, but…is it? Nowadays you have enough computing power on most projects so it won’t be a big difference, and if you have a lot of juniors in your team, a switch might be your answer. Just think about cognitive complexity and you’ll get me. It is almost always more important the maintainability than a standardization you or someone else made for you and your team.

Find potential bugs and implementation flows. Ask those questions with “What if…”.

Knowledge share! In many code reviews, I saw people adding comments, probably just for fun (like: you used here tabs and not spaces; You should have used extension methods here and not private methods in the class because it looks better). If you have a personal preference, talk with the team, or talk with the person who wrote the code, but don’t block the PR with such nonsense. Share why you like “your way” so much, and come up with KPIs or numbers in general, but if they are not improving the code by a lot, just write it down as a tech debt if you both agree and move on.

Don’t do this!

Don’t block PRs for issues without a real impact. If you don’t have a number for it, you either create a KPI first and for now keep the issue as improvement or tech debt, convince the entire team why this is important and it needs to be changed, or the last option would be, just to ignore it. Win the war, not the battle.

Don’t write ambiguous comments. It’s just unprofessional to read a comment and not understand what the writer is thinking, what he is suggesting or what he wants you to do next. The aim should be to have clear, specific, and actionable changes asked.

If there are more than 3–5 comments, just schedule a call to talk them out. Even if you don’t want to have your camera on, having an audio conversation is more useful than just having a comment.

Things to consider

You must inspire others, you must convince others, so the right direction is to promote trust, and respect and push for collaboration. When you talk to a person on a code review, show empathy and set an environment for the discussion for a continuous learning culture.

People tend to forget that a code review, in the end, it is a feedback. This impacts directly the team's mood, confidence level and well-being (whatever role you have in the team).

You’ll want to be a respected team member and people to trust you, learn and have fun together. You need to make the correct step, and probably the first one also. Be sure no one is feeling judged. We both talk about the code, not the person.

Your “actions” can help someone grow or can destroy his/her confidence and make him/her mad. Which one do you want to happen?

Conclusion

Good code review comments differ from one team to another. In one team your comments might be “the best”, in another, they might be useless, but if you have a code-review mindset, to change your “style” it will be pretty easy.

I won’t write any “DOs”, because there is no magic recipe for how to do it. Read carefully the things to consider chapter and if you have some more time, take your chance with the guidelines from my old article. Create your own “style” and just try it out and adjust.

Be agile, change based on your team, and have fun!