I was once accused of being a code bully, and was shocked (and dismayed) at the accusation. While I’m very opinionated (which is the whole reason for this blog), I try to be very open to criticism and discourse, so it left me pretty shaken when I got that feedback (though I later found out it wasn’t as bad as the person delivering it made it out to be, which was a great source of relief).

But learn from my mistake – if you’re new to code reviews, find out from another developer what the team’s “standard operating procedures” are. What I didn’t know was that in the team I was working in, it was considered bad form to push back against any proposed changes by someone reviewing your code. This isn’t always obvious when you’re first doing code reviews – for someone like me, I wanted to engage with the reviewer, and my way of being engaged was to really question what the value was in their proposed change, so I could then (hopefully) understand it. In reality, this was seen as being argumentative. ☹

With my background as a project manager, I was used to being very cautious in the face of proposed changes that add any development time, particularly if I think they’re just some “syntactic sugar” that I wasn’t familiar with. (A working example: list comprehension in Python, while always cool, does not always create more readable/performant code, afaik, and can make things less readable for a Python novice.)

As a former PM, I tend to be skeptical about that type of refactoring, which from a project management standpoint appears to add no value to the stakeholders. (And becomes very hard to explain, very quickly.)

But I needed to change my attitude as a developer, when my primary responsibility is to the integrity of the code.

As a developer getting a code review, pick your battles with extreme care, or you might be seen as a code bully!