‘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.
↓ click the "like" button to share on twitter and facebook!