The Four Principles of Code Review

Introduction: Happy Father's Day, It's An Algorithm!

If you're reviewing somebody else's new code, you better be doing it on eggshells.

The autistic developer is in love with his code. He treats every program as a child, and hopes for nothing but a long and stable future, one in which his program listens to everything the coder says.

That rarely happens: programs are like little children: they grow older and turn into teenagers. They become trucculent, sullen and sulking. They start to think they know more than you and they start to answer you in that way. I know you wanted me to return an array, it will say, one day, but you're so out of touch with the way things are, that you're wrong. I'm going to send you back a literal. Deal with it, dad.

It's not the fault of the code. It's the fault of the programmer, who loved his child too much, who created it and adored it so much he refused to recognize all of its flaws. And he could never quite fix the ones that he left to be fixed or found tomorrow.

You may be unlucky enough to review code after its birth. You may be so unfortunate, that the proud father will present you his bundle of joy, his creation, his work of art, and he will say to you, 'please code review this.'

What he means is, 'please tell me how beautiful my baby is.' Now you're stuck, because what kind of a pompous ass crititicizes a newborn baby?

When reviews of brand new code happen, no one listens to criticisms, because no one truly believes there could be something so wrong with the code that they didn't see the problem themselves. The developer thinks, the problem isn't me, it's the code reviewer: he just doesn't get it.

So good luck with it. Because when you are the code reviewer, you probably don't get it. Few people do.

Next: The First Principle of Code Review: Check Your Ego