When we spend time on a piece of code, we can feel like that code is a part of us. Criticism about your code can feel even worse than a seemingly more personal criticism, like comments about appearance. We can come to feel like our code is a reflection of who we truly are—how we think, how skilled we are, and whether we even deserve to be where we are. With this viewpoint, any feedback that something isn’t right can feel not like a comment on the code, but like a personal attack. Someone telling us that our logic is wrong might be interpreted as “you are not good at your job” or “you are not smart enough to be here.” However, this sense of attachment makes a productive code review impossible.
In order to actually hear that feedback and to improve the code, It’s important that we detach ourselves emotionally from code. The fact is, not everyone is there yet, and saying anything negative about their code will raise their defenses. For the developers submitting code for a code review, learning to see code as separate from self is critical. It can take time and maturity to get there, but it is worthwhile to try.
Creating a culture of safety
A key aspect of pull requests is that they are very much a two-way process. Learning to emotionally detach oneself from code requires a team effort to create a culture of safety. Only when code reviewers go out of their way to accept and respect the developer while giving their feedback will a developer find the space to have the confidence to truly hear feedback as a way to improve the overall project, and as an opportunity to grow. Without that consideration from reviewers, a defensive attitude is going to be the natural, human response, and we really shouldn’t expect anything different from people.
A reviewer must communicate their feedback in a way that will be heard. It’s not always easy though—much like developers tie their identity to their code, reviewers can fall into the trap of tying their identities into tearing down other people’s code. Pull requests should never be about making someone feel bad (even unintentionally)—they should be about helping the submitting developer improve the code at hand, and to understand and grow. Presenting the feedback in a way the submitter will hear it is important: Make sure to be specific as to what improvements are required and keep the tone positive.
As a pull request reviewer, you may sometimes feel angry or frustrated, but your GOAL is to give feedback to get the pull request fixed and then approved as quickly as possible. Expressing that frustration in your pull request response can turn the entire pull request into an emotional, defensive discussion, instead of one that is headed to being finished quickly.
Explain, don’t command
Another aspect of being heard as a reviewer is explaining in order to get buy-in. Nobody likes a dictator, and that applies to pull requests as much as anything else. Explaining why something needs to be changed shows that you’re not just making decrees on whim, you’re providing guidance based on reason. Decrees breed reactionary opposition, which is the last thing you want as a reviewer. So, even if you feel that your reviewee doesn’t NEED to know the reason, it’s worth the time to give an explanation, not just move things along, but to gain the trust of your reviewee. It’s a way to treat the pull request submitter with respect: They are an equal who deserves to hear your logic and, again, people are more likely to hear your feedback when it comes from a place of respect.
Successful pull requests are not just about the code, they are about people and communication. Consider how pull requests are a conversation between submitter and reviewer. If submitters are better-prepared to receive feedback gracefully, and reviewers can deliver feedback in a way that will be heard and accepted, the review process can be a shared learning experience that results in more trustworthy code—instead of a futile exercise in stress.