(Follow-up for my previous post on how to write good code from scratch.)
No, I won’t ask here to always write unit and automated UI tests, although they would also help tremendously at the time our code would be stable enough.
And I can’t ask anyone to show and explain code to somebody else either, although it would be a brilliant idea: I’m sure you do remember a few times when you spotted really strange issues in your code while simply explaining it to (silent) colleagues, but I also know that most of our peers are always busy and probably can rarely help that way.
Finally, let’s also exclude the rubber duck and any other awkward peer impersonations: code matters, but come on, never that much!
Yes, another real pair of eyes could surely help, and I’m not against team-level code reviewing techniques that our organization may have already adopted. But I think that peer reviewing alone is not the full solution towards what we really want here.
Instead (or before requesting a review), I suggest to just carefully browse that code, and add detailed inline comments to it.
As if they were to be read by an important possible customer, that asked for automatically extracted random code slices before initiating a big purchase we were waiting for so badly. Explaining everything with simple English, yet completely and in a consistent manner – like a (dev) pro!
You’ll be amazed to see how many things – minor or major – would be refactored during such commenting sessions: from simple variable renames to reorganizing code for consistency reasons, and from complex logic restructuring to deep algorithm optimizations.
(Yes, this does take more time than any live discussion, but it would require no other person’s presence whatsoever. And the comments we’d have added may further help years later too, when we’d just need to remember some deep details about our complicated system, or – who knows – even allow us to eventually sell that source code to a real customer if we’d ever wanted to!)