You’ve just finished working on a big feature for a project you’re newly a part of. You’re proud of the work you’ve done and are confident that your solution belongs in a code museum of some sort. You create a pull request, ask other developers to look over your work, and then sit back and relax.
But the next time you look at your pull request, you find comments pointing out several potential issues in the work you’ve done. Are you actually a terrible developer? Of course not.
Getting past this type of thinking is a big part of growing as a developer. It involves both learning how to take feedback from other developers and reflecting on your own work. Here are a few things to keep in mind when receiving a code review.
1. Separate Yourself from Your Code
A common trap new developers fall into is to tie their code to their own worth as a programmer. It’s important to remember that you are not your code. All developers make mistakes, which is exactly the reason code reviews exist in the first place. Don’t take personal offense when the solution to a problem you worked hard on gets dismissed by others. Separating yourself from your code will help keep you from dismissing important feedback.
Moreover, when you can separate yourself, you can look back objectively on your work and learn from it. You can’t learn from your mistakes if you struggle to accept that you make mistakes.
2. Don’t Be Afraid to Defend Your Decisions
Just because another developer has disagreed with your code doesn’t mean you’re not allowed to defend your code. Many new developers will take a code review from another developer as sacred. They will assume that because others disagree with them, they must be wrong. A code review is not a one-sided affair; it’s a conversation where both the reviewer and the reviewee’s perspectives are welcome.
When someone questions the way you’ve solved a problem, don’t immediately disregard your own thinking. Think through the feedback they’ve given, then respond with your reasoning. A respectful back-and-forth is the essence of an effective code review, and it results in effective code.
This also applies when giving code reviews to others. Many new developers will ignore their own concerns when reviewing someone else’s code, especially that of more senior developers. If there’s code you don’t understand or feel concerned about, bring it up in the code review. Either you’ll get an explanation on how the code works, or you’ll discover an issue the developer was unaware of. It’s a win-win situation!
3. Understand that Everyone Has the Same Goal
Both the reviewer and the reviewee have one common goal: to produce quality code. That’s why it makes sense to separate yourself from your code. Once your pull request gets approved and merged, it no longer belongs to you. It belongs to everyone on the team. Quality code is in everyone’s best interest.
On a good team, everyone also shares the secondary goal of helping you learn to produce quality code. It doesn’t do anyone any good if developers on the team never grow their skills. A team with well-written code reviews is much healthier team than one that gives a single thumbs-up emoji on all code reviews.
Code reviews can be a large source of anxiety for new developers. Remember that they are an important part of software development, regardless of how many years of experience you have. Staying open to feedback will allow you to grow as a developer.