August 01, 1999
Overload 33 Editorial
For Sam's birthday we repeated our honeymoon at The Boathouse in Phuket.
Posted by John at 12:00 PM
February 01, 1999
Overload 30 Editorial
Dear Readers
Whilst wading through the swamp of files on my hard disk I realised that this is my eleventh issue of Overload. It doesn't seem long since I wrote in the Overload 20 editorial page:
"Hi folks. I've been appointed editor for the next three issues. If this role suits me, and more importantly suits you, then I hope I'll be here for some time."
That was nearly two years ago. So, it must be time to shake things up a little! I'll be shirking my editorial responsibilities for the next couple of months. Einar Nilsen-Nygaard, one of our esteemed Readers, has agreed to edit Overload 32 in my stead.
Ray Hall, another member of our editorial board, has written to resign his position…
"I was reading the December issue of Overload on the train this morning, having been busy when it arrived, and observed that I had missed the January deadline. Although 1998 had been the year of the pig in the Hall household, I was still somewhat abashed to find that I had done nothing for Overload in that time.
I think therefore that you should remove my name from the list of credits at the end, since it raises false expectations. I will still be happy to comment on, or sub-edit, any pieces which you may throw at me, but I am not in a position to allocate time to initiatives. (In fact I am programming in Delphi, writing a book on music and planning to move house properly…)"
We thank Ray for his contribution to Overload and wish him well with his endeavours.
Volunteers now take a step forward please. For we need to recruit a replacement Reader from the membership. The duties are light and of course the work is highly rewarding. Generally we need someone willing to read submissions for technical and language correctness. But, you can pretty much make of it what you will; taking a role that best suits your knowledge and skills. It'd be great if someone could revive and maintain the dusty Overload website, or could spend their time finding and nurturing budding new authors. The greatest threat to the survival of Overload is that so few first time writers are coming forward with their ideas.
Books
Whilst Einar is working on Overload 31 I'm going to be catching up with a couple of my other extra-curricular projects.
I recall Nicolas Negroponte writing in Wired that he only reads books during his yearly month of vacation time. For eleven months of the year he buys books and has them delivered to his Greek holiday home. A month of books, and no doubt fine wines, sounds like bliss. I only have time to buy the books, not actually read them. They're stacked up all over my home and my office in roughly categorised piles, just waiting for another package to arrive and its contents distributed across the stacks.
I've been buying all my books online at Amazon.com and Amazon.co.uk. But, I recently read about this…
Printer's Ink
A local, slightly offbeat, bookstore closed recently blaming its fate on a new breed of book buyer. The customer comes to wander the aisles and browse, has a coffee, and then goes home to save a few bucks by buying the books at Amazon.com. My feelings are drawn here, for I love bookshops, but I also love Amazon. I find that I don't actually have time to go shopping, but I do have time to surf shop. It's the immediacy of it… a couple of clicks and another batch arrives two days later. But, I don't want those bricks and mortar stores to fade away. Wherever I travel I want to visit the landmark bookstore. Dillons and Foyles in London. Blackwells in Oxford. Heffers in Cambridge. City Lights in San Francisco. Computer Literacy in San Jose. And, Printers Ink in Palo Alto. But, I think Amazon is wonderful. I even bought shares. But now I feel so bad because maybe it's all my fault.
My online book buying fetish has now been extended to www.alibris.com. They specialise in out-of-print and rare books. Packages from them are now feeding my most obscure literary tower. The Economic and Social history of early 20'th century Chicago. Otherwise known as Gangsters… By explanation I can only offer up one of my other distractions www.tightbeam.com/godfather.
Farewell until Overload 32. But, remember to support your local bookshop and your favourite magazine serving all your C++ and OO needs.
John Merrells
February 1999
Posted by John at 12:00 PM
December 01, 1998
Overload 29 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 J.
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
December 1998
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!
Posted by John at 12:00 PM