William Edwards, Coder

The Lost Art of Code Reviews

‘Desk checking’ (proof reading) is almost a lost art in 1993. Too bad. You should desk check your code before even compiling it, and desk-check it again periodically to keep it fresh in mind and find new errors. If you have someone in your group whose ONLY job it is to desk-check other people’s code, that person will find and fix more bugs than everyone else combined.

‘I’m running a Mud so I can learn C programming!’ Yeah Right. Merc MUD v 2.1 1993

When I was at Symbian/UIQ, code got reviewed.  My code got reviewed, I reviewed code.

The more senior engineers might spend as much as 20% of their time - 1 day per week - checking other people’s code.

Before some new component or program got released, software architects would be seen coming back from the laser printer with a thick wad of source-code to look through.

Before some new component or program got released, the more experienced and enterprising coders would be seen going around desk-to-desk handing out thick wads of source-code to ensure people looked it through.

You quickly worked out the relative competence of your peers by paying attention to the issues they raised in code-review and how deeply perceptive they were.  The more superficial the issues raised, the lower they scored in your mind.

Working with smarter people makes you smarter; it rubs off; you learn.  Being reviewed, watching reviews and becoming a reviewer was the best self-development possible.  Its knowledge transfer.

The more senior the engineer the more they would themselves want their own code scrutinised, reviewed.  This wasn’t the juniors being humoured by the seniors; this wasn’t the juniors being sport or entertainment for the seniors.  This was the search for excellence and the building of teams.

If you are in a position to influence how your peers spend 20% of their time you should rediscover the lost art of code reviews.