Code reviews are perhaps one of the most important parts of professional software development - routinely having peers take an earnest look at your code and suggest improvements ensures that the quality of your entire project goes up throughout its lifetime.
Many of us aren't comfortable with code reviews. We're distressed by being under the microscope, our intelligence and skill measured in our level of familiarity with the patterns and idioms our peers are using. We don't want to be caught looking like an amateur. Like all humans, scrutiny frightens us.
The Litany Against Fear from Frank Herbert's "Dune" can be turned to our purposes here.
"I must not fear code reviews. Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit scrutiny to pass over me and through me.
And when it has gone past I will turn the inner eye to see what I can learn.
Where the fear has gone there will be nothing. Only better code will remain."
We need to be able to let our fear of code reviews pass over and through us, so that we can move on, learn from our peers, and write better code. Here are some things to keep in mind that can help you get over your discomfort.
You're not expected to be perfect: It's assumed that proposed changes from anyone on the team should and will receive suggestions for improvement regularly. A comment on your code isn't a rebuke.
It's not about distrust, it's about code quality: Your teammates aren't second guessing you and double-checking that your work is up to snuff. A code review's primary purpose is to ensure that the resulting state of the source code after your change is of high quality and is as consistent as possible across the entire project. That means...
It's not personal: The reviewer is not critiquing you, your skill, your knowledge or your intelligence. They're probably not even thinking about the person who wrote the code they're poring over.
Not All Comments Are Criticism: Some comments on PRs will be inquisitive rather than prescriptive, drawing your attention and asking if some detail was intentional or if you considered some edge case. "Oh hey, did you account for x?" rather than "Hey, you did this wrong."
Sometimes the reviewer is mistaken, and that's okay: If you genuinely think your code is correct and a reviewer is calling it into question, you can simply explain the particulars and your thought process, and why you think your change should stand. If your tone isn't defensive and confrontational, the reviewer won't take your disagreement as such.
If you keep these things in mind and learn to stop fearing code reviews, we can all enjoy keeping our code quality up and learning a little more from each other every day.
A Litany Against Fear (of Code Reviews):
- You're not expected to be perfect.
- It's not about distrust, it's about code quality.
- It's not personal.
- Not all comments are criticism.
- Sometimes the reviewer is mistaken, and that's okay.