Have you ever met a developer that is? Are you one of them?

These are the guys and girls who hate it when others work on their code. They get very emotional about the fact, and treat the maintainer like the cause of a relationship gone sour. The new boy- or girlfriend of an ex-lover.

I sometimes wonder what motivates this behaviour. Do they believe their code is a work of art, intended for all to praise and adore, without regard of what it is or isn't doing? Might it be, that they hate being second guessed about their approach to a problem? Is it possible they believe they are right, regardless of proof to the contrary (Don't laugh I've met a few of these)?

Either which way. The only way you can ever be sure your code is doing the right thing at the right time, for the right reasons while performing to standard. Is when it is running and passes user scrutiny, while performing within no more than a fifth of the acceptable time and space.

Yes, I am deliberate with the statement above. No program is ever perfect! Or, stated in another way; all programs can be improved.

Some developers seem to attach to much weight to their code, and not enough to what it ends up doing or not doing. Thus, when the time comes for someone else to fiddle and repair or even completely rewrite their application, they throw the developer's equivalent of a temper tantrum. I'm sure you've seen them, they are either completely silent or overbearingly loud.

Personally, I've learned to love being second guessed on my code. Being able to argue, civilly, my point of view on a problem and receiving another's approach, has proven to be very enlightening. I've learned more in 3 hours of code review than 6 moths of Computer Science courses. Maybe this stems from my love of debate, but it has certainly turned me into a much better developer than I would have been otherwise.

This also leads to far more robust programs landing on the live platforms. Which invariably makes me look good to the powers that be.

In the end though, I could not care less about the code. I measure the value of my applications in terms of how well they perform, how maintainable they are and how well they are documented. The code is only a means to an end. Just a tool I use in order to solve real world problems.

Next time you run into a code review, ask your reviewer to be brutal. Not about the code, being brutal about the code is useless, you just end up having a coding standards meeting. Be brutal about the solutions to the problems at hand.

“Is there a reason you chose this algorithm over that one?”
“Why use a linked list when a map would have been easier?”
“This might execute faster if implemented according to such-'n-such design pattern.”

Those are the comments and questions you are looking for, statements like: “Why did you use a ternary operator when an if-else is more readable?” do not aid the situation. Don't bother with syntax and style unless it's obvious, that the code will be unmaintainable.

Think of the code reviewer as the pastor or priest. When he puts the “GOOD TO GO” stamp on your code... You may kiss the code. :)