I always feel pressure and embarrassment when doing code reviews. What should I do?
One of the best things you can do is discuss how you feel with your manager. A good manager will help you overcome your problems. That’s what they’re supposed to do. When somebody on a team has a problem, then it can affect the whole team. Removing obstacles like this helps everybody. It’s possible that your problems are due to another teammate. That’s something that your manager can help with too. If you have a team or even a single person on a team that reacts strongly and loudly to anything other than glowing praise, then it’s going to be difficult to review code. It’s the job of the manager to correct problems like this too.
One thing you can do if you’re just joining a new team is to read previous code reviews. Get a feel for how other team members express themselves and how they react. Many times, a misunderstanding is caused just because we can mistake a person’s normal behavior as being directed at us instead. Reading old code reviews will help you learn who is shy, who is outspoken, who responds well to questions, and who needs facts.
We’re all different and there’s a common lesson taught in early grade school called the golden rule. It says to treat others the way you would like to be treated. Unfortunately, that rule is backwards. Following it can sometimes work and sometimes cause even more problems. Remember, we’re all different. That’s the key. Don’t treat people the way you want to be treated. Treat them the way they want to be treated. Within reason, of course.
What I mean is, let’s say that you like direct, to-the-point communication. If it’s wrong, you’d rather somebody just tell you right away even if the whole team knows. This lets you fix it and move on. Another person might be horrified by this and may prefer a question to give them time to think about it and change their mind on their own. If you try to treat others the way you want to be treated, then you’re almost certain run into problems that are unrelated to any technical code review points.
Listen to this episode to hear my thoughts on the following questions about code reviews:
- What if I’m too busy with my own work?
- What if I don’t find anything wrong?
- What if I don’t find all the problems?
- What if I suggest something that turns out to be wrong?
- What if somebody else finds something I should have caught?
- What if I catch a mistake that the developer should not have made?
- What if this is not the first time for the same problem?
- What if the developer pushes back?
- What if my comments are ignored?
- What if my comments cause hard feelings?
You can also read the full transcript of the episode below.
Transcript
One of the best things you can do is discuss how you feel with your manager. A good manager will help you overcome your problems. That’s what they’re supposed to do. When somebody on a team has a problem, then it can affect the whole team. Removing obstacles like this helps everybody.
It’s possible that your problems are due to another teammate. That’s something that your manager can help with too. If you have a team or even a single person on a team that reacts strongly and loudly to anything other than glowing praise, then it’s going to be difficult to review code. It’s the job of the manager to correct problems like this too.
Every situation is different and in a way you can almost think of this entire episode as sort of a review. Not a code review. But a review of possible scenarios that I try to think of and then ways you might be able to learn and adapt.
Eventually, code reviews should get better over time but some aspects should remain.
◦ For example, nervous feelings can help as long as they’re not too strong.
◦ Your confidence will improve over time. As long as you take each review as a learning opportunity, you’ll get better.
One thing you can do if you’re just joining a new team is to read previous code reviews. Get a feel for how other team members express themselves and how they react. Many times, a misunderstanding is caused just because we can mistake a person’s normal behavior as being directed at us instead. Reading old code reviews will help you learn who is shy, who is outspoken, who responds well to questions, and who needs facts.
We’re all different and there’s a common lesson taught in early grade school called the golden rule. It says to treat others the way you would like to be treated. Unfortunately, that rule is backwards. Following it can sometimes work and sometimes cause even more problems. Remember, we’re all different. That’s the key. Don’t treat people the way you want to be treated. Treat them the way they want to be treated. Within reason, of course.
What I mean is, let’s say that you like direct, to-the-point communication. If it’s wrong, you’d rather somebody just tell you right away even if the whole team knows. This lets you fix it and move on. Another person might be horrified by this and may prefer a question to give them time to think about it and change their mind on their own. If you try to treat others the way you want to be treated, then you’re almost certain run into problems that are unrelated to any technical code review points.
Right after this message from our sponsor, I’ll continue with ten scenarios and things you can consider to improve.
Here’s ten questions I thought of that will hopefully help you become a better code reviewer and feel more comfortable.
#1 What if I’m too busy with my own work?
◦ This will definitely happen sometimes. Don’t worry about it. That doesn’t mean you should ignore it and keep doing your work. Let the team know that you’re busy and ask for guidance about priorities. Maybe the code review really is more important than what you’re currently working on. Or maybe the team will get somebody else to help with the review. The important part is that by being open and clear about your priorities, you no longer have to feel guilty about not doing the code review.
#2 What if I don’t find anything wrong?
◦ And as a follow-up, do I have to make a comment? The main thing here is to give each code review your full attention. Even if several other team members have already approved the changes, don’t let that distract you. If you really consider the changes and they look good, then go ahead and approve them. And it’s okay to post a positive comment. If you really like something, mention it.
#3 What if I don’t find all the problems?
◦ Well, the important thing to realize is this is the whole reason for code reviews in the first place. Nobody can find all the problems all the time. It’s okay. Do your best. If another team member catches something that you missed, you might want to ask that person what questions you could ask in the future to catch similar problems.
#4 What if I suggest something that turns out to be wrong?
◦ You generally want to avoid making absolute statements. Stuff like, “This is wrong.” can come across as a superior tone. Worse yet, is if you describe how stupid something is or resort to insults. And if it turns out to not be wrong, well, then you just learned something. And hopefully part of that learning involves having more respect for others.
◦ Ask questions when your unsure. But don’t forget that a question even when you are sure, can be a good way to make the other person less defensive.
#5 What if somebody else finds something I should have caught?
◦ Just realize that this is a team effort. Congratulate the other person and don’t beat yourself up over it. You might also want to think about why you missed something. Were you not paying attention? Were you in a hurry? Did you not understand something? Take the time for a little personal review to see what you might be able to do better next time.
#6 What if I catch a mistake that the developer should not have made?
◦ Again, we all make mistakes. And it’s a team effort. However, if you think a review comment could cause the other developer problems, then consider speaking privately first.
#7 What if this is not the first time for the same problem?
◦ Here, you might want to consider things like, Is the same person responsible? If so, then try mentioning it to the other person privately. If it turns into a habit, then it may be something that your manger should deal with. If it’s not the same person, then maybe the team needs some extra training.
◦ Another thing to consider is, Was the last occurrence a long time ago? If so, then maybe you could suggest to your manager periodic training or a refresher every so often.
#8 What if the developer pushes back?
◦ Many times, this is a perfectly valid response. So don’t take it the wrong way. Stay respectful and make sure that everybody understands the purpose of code reviews is to make the project better.
#9 What if my comments are ignored?
◦ This can be a tough one. But the biggest reason I can think of goes back to the golden rule. Maybe the other developer needs a stronger review comment in order to take notice. Ask yourself if you really did everything you could in order to be heard? And not just in ways you would have heard yourself. But in ways that the team or the other developer expects.
#10 What if my comments cause hard feelings?
◦ All I can say here is to be respectful. Sometimes feelings do get bruised. Don’t make the review personal. Stick to the current review and don’t call up past mistakes. And word your comments about the code and not about the other person.