We’ve all written our fair share of code. Sometimes it’s elegant and well-reasoned, and sometimes it’s convoluted and flawed. No one is perfect. There will always be that moment where you look at code you wrote a year, a month, a day ago and say “What was I thinking?”
So it stands to reason when someone else is reviewing your code, or just happens to stumble upon it one day, they could have the same thought. Maybe they have a different solution in mind. Maybe they see a bug you missed. Maybe they just don’t like the way it reads. For one of a million reasons, they could decide your code is lacking in some way. And, in all likelihood, it is.
“Two heads are better that one”, “a fresh set of eyes”, choose whatever idiom you’d like. The truth of the matter is that having someone else’s comments on the code your wrote could help improve it. Let’s even go a step further, and say that their input could even help improve you. There could be a library you don’t know about, or a best practice you haven’t learned yet, or maybe your code just isn’t clear enough.
Chances are you already know this. You understand the value of peer review, and its potential benefits to you and your code. But here’s the problem. When you write code, you’re creating something. And when you create something, you feel responsible for it. In some ways, the code you write is an extension of yourself. So when someone pays a compliment to your code, by the transitive property of code reviews, it’s like they’re complimenting you. But the same holds true for less favorable commentary.
It’s instinctual to feel insulted or defensive when someone criticizes your code, because that critique is bound to act the same way the compliment did. What was originally meant as friendly advice or a harmless question can easily be misinterpreted as a personal attack on your competency. It’s in these moments you have to take a step back and realize that sometimes code is just code. Critical and logical thinking are core skills for a software developer, and objective reasoning is just an extension of these skills. Only when you listen to a review of your code rationally can you benefit from it.
Disconnecting yourself from your code can be hard, and it’s not always a good idea to. Accepting a compliment on behalf of your code is not only a great feeling, but it also helps build confidence and reinforce good practices. By the same token, you should feel responsible your code so that you don’t just rush some horrible spaghetti code out to production and abandon it in the bowels of legacy code.
Staying objective can be hugely beneficial in everyday life, not just in the workplace. If you can apply reason and logic to your daily problems rather than just getting frustrated or upset or angry, you’ll realize that every problem has a solution. That being said, we aren’t Vulcans. Emotion will always have a role to play, and it’s part of what makes us human. Just be able to identify when your feelings betray you. (Yes, I realize I made a Star Trek reference and followed it up with a Star Wars quote. Deal with it :).)