Tip – Avoid Being on the Defensive

Writing code can be a hugely satisfying exercise. When you’ve finally cracked the solution to that problem you’ve been trying to solve for hours or even days, and the code just flows from your fingertips, it can leave you with a great sense of achievement and confidence. And rightly so. 

Unfortunately, however, the reality of it is is that not everyone is going to agree with your approach, and not everyone is going to care for your code in the way you have. Come code review time, people who have spent little to no time on it at all will quite happily question your work, ask things that in your head, seem obvious. This can often leave you feeling rather protective over your work and if you’re not careful, make you appear defensive. 

The more time you’ve spent on your code, the more this feeling of being protective tends to develop. Especially if it’s something you’ve worked on exclusively on your own. 

Code reviews and other similar exercises are a crucial part of any working environment where code is being written. To not have a code review process is a disaster waiting to happen, and will only come back to haunt you later on when things start going wrong. 

Because they are so key, you have to get used to the idea that any code you are writing will be picked apart by at least one other person. But the important thing to remember is that their comments or feedback aren’t an attack on your ability to code or your coding style, it’s a process of improvement, and enforcing coding standards. 

It’s your job to be prepared for this. It’s only too easy to submit code for a review already on the defensive. Especially if the reviewer is someone you may not always see eye to eye with when it comes to coding approaches. 

If you’re anticipating comments about a particular section of code or an approach you’ve taken, then deep down you’re probably already aware that it might not be quite right or in line with the rest of the codebase. If this is the case, try and address those concerns before you submit your code for review. If you feel that it is the right approach and you can justify it, do so before hand and speak to the reviewer before the code goes in for review so that they are aware. 

If you feel comments are unfair, or they are missing the point of what you’ve done or even just don’t understand, then again, don’t take it as criticism or an attack on your code. Speak to them, take the time to understand their concerns and make them aware of the logic behind your code. This will benefit both parties. The reviewer will now better understand what you’ve done and why you’ve done it so can better review your code. And you will now better understand any comments or concerns they still have. This reduces the need for back and forth comments. 

I’ve been guilty many times in the past of coming across as quite defensive or even aggressive in code reviews to peoples comments or questions, especially when I first started writing code in a professional environment.  But it’s only later on in my career when I’ve been the one doing the reviews where I’ve appreciated exactly what it is they are trying to achieve and how people can feel. 

I think the from a reviewers point of view, it’s important that any questions or comments are constructive and come across that way. Some times it’s easy to make comments that can be quite dismissive of peoples ideas or quite abrupt when making a suggestion. When this happens, as the coder, you must try and understand what the goal of the review is and try not to look too much at the wording of the comment. 

The other issue with being defensive over your code is that it can often lead to strained professional relationships. People can often view you as difficult and will hesitate to ask for help or advice, if they think you’re closed minded to new ideas or ways of thinking. This not only affects your ability to work, but the team as a whole if the team isn’t cohesive. When that happens, it has a knock on effect for everyone. 

But despite everything I’ve said, being protective over your code is only natural, it’s something you’ve invested time in and it’s possibly the product of some clever thinking and problem solving. Having that passion and enthusiasm to the point you actually care about your work is great, and shouldn’t be discouraged. Instead you should use it constructively, take the feedback and suggestions as a way to improve not only the immediate code they are reviewing, but also any future code you may write. Sometimes that suggestion that annoyed you or you thought was nonsense at first, will actually make a lot of sense if you look at it with an open mind. 

Appreciating the fact that there are many ways to approach any problem in coding helps you massively going forward. So hearing those ideas and alternative approaches, even if you and the reviewer decide they aren’t appropriate this time round, will mean next time that you have even more tools under your belt to approach a particular problem. 

The most important part of coding is that you enjoy it. It’s a wonderful thing to have the ability to read and write code of any language. Embrace that and the notion that everyone thinks differently, and take all of it in like a sponge.