Title: Editorial

I've been thinking a little lately about the aesthetics of software. By which I mean, what is it about a piece of code that makes you feel good or bad? Not the high level things like design or architecture, but the reams of code that make up the implementation. Good code has properties of being neat and tidy not scrappy, readable and manageable not sprawling, complete and well formed not lacking or flabby. Can you feel the goodness oozing from it?

I've been programming machines for about 17 years now - and I'm only on the verge of thirty. But, in that time I seem to have built up instinctive feelings about what's right and wrong with code at just a glance. I find myself with these strong views about the way that things should be. But, when I question those views, I find it difficult to remember the experiences and reasoning that they are based upon. We are all continually learning and re-learning, and that process isn't just listening and reading, it's speaking and writing. This is where organisations like the ACCU and publications like Overload fit in, they are a medium for telling and re-telling the software tale.

What started me thinking along these lines was that my project team is split evenly between senior and junior engineers. There is no formal means for the body of collected experience to be passed on. Mentoring is where I'm headed. But, I don't think I've ever encountered a formal mentoring scheme that actually worked very well. So, perhaps an informal scheme is required.

Mentoring benefits the experienced too, by helping them develop the skills of expression. As I've said before, you don't truly understand something until you're able to explain it coherently to someone else. Many software engineers are held back by their inability to express, or perhaps even sell, their ideas to other people. This was actually one of my personal motivations for becoming involved in Overload. I've always been dreadful at spelling. In fact, as I look back on my early years I'm becoming convinced that I had some form of dyslexia. For example, I couldn't tell the difference between the letters 'b' and 'd' for many years, and I still have trouble with the concept of 'left' and 'right'. Seemingly bizarre, but true. My wife has taken to communicating driving directions with exaggerated expansive gestures. So, Overload is my aversion therapy! Forced to write a page every other month is actually harder than you think - but, highly beneficial, and practice is the only way to get comfortable at it. So, I suggest you try it ☺.

Anyway, two informal mentoring schemes I've tried are chalk talks and code reviews.

Regular lunchtime presentations work very well. A team member presents something of general interest to the group. This gives them some presentation experience and, by keeping things informal, promotes group discussion. Topics that have been aired of late in our conference rooms have been 'Debugging Techniques', 'COM like patterns', and the more esoteric 'Public Key Infrastructure' and 'Corporate Finance 101'.

Formal code reviews are often used to ensure code quality and to identify defects by inspection. I've also found them very useful for focusing a discussion about appropriate and inappropriate techniques and ideoms. It's much easier to talk about the dos and don'ts of writing code if you've got concrete examples to point to. Learning about the wrong things to do is just as important as learning the right things to do. Making mistakes isn't a negative thing if you learn from it.

Peer review can also have a wonderful motivating effect on code quality - but only if announced at the start of the project - it has little effect if sprung at the end. I believe the psychological effect that your peers are guaranteed to be pouring through your code encourages responsible behavior.

So, in conclusion, I'd suggest you consider becoming a mentor or finding a mentor, or indeed both.

John Merrells <merrells@netscape.com>

PS: There's actually a third mentoring scheme I highly recommend. It's called the 'Friday Pub Lunch and Two Pints of Beer' scheme. I'm planning on trying this here, but I need your help. I need you to write up your software tale, or send me a case of Young's Special. Not the Stout. Not the Ram Rod. But, the Special!