Celebrating Margaret's 25th year at Village

Last week we celebrated Margaret’s 25th anniversary at Village. From her accidental fall into programming many years ago while inventing a function-like notation for knitting patterns, she’s spent her entire professional lifetime offering both a logical brain and different perspective to her clients.

While she’s lost count of the number of languages she’s picked up over the years, what makes her particularly valuable is the wealth of experience and wisdom she’s acquired. On Wednesday she held a seminar to pass on some of that knowledge to us more green developers. Here are just a few of the insights she had to offer:

People talk when they’re passionate about their project. It’s easy to come away from a scoping discussion with a potential client feeling really clear on their vision and confident about what they want.

Nevertheless, it’s sometimes hard to quantify their desires as deliverables. A lot of conversation time gets given to explaining the possible impact of one’s vision on the organisation, and is filled with words and phrases that don’t affect the functional or practical requirements of the system. Or perhaps what they were talking about turned out to be beyond the scope of what you expect to be doing. Maybe what they want is just immeasurable – good UX design is much more than a clear layout, using appropriate fonts and colours.

What can be helpful is to 'cross out' any notes that don’t affect your estimates. By vacuuming up any extraneous distraction you can see more clearly what you’re offering and, perhaps more importantly, what’s missing. The corners they haven’t considered are the source of most of the problems a project might come across. This routine allows you to go back for more targeted discussions and flesh out the areas that were ambiguous.

All this isn’t to say those crossed-out words were useless. They give clues as to what’s important to a client and how effort should be split up. They might give leads for future work, or suggest a particular shape of design solution. They teach you about this client’s communication style. All of this is interesting, but isn't the focus of a specification review or an estimate preparation.
 

Margaret holds a seminar to pass on knowledge gained in her years in software development 

It’s also worthwhile checking your vocabulary assumptions. Common words might have specific meanings in the context of a business, or even different meanings across different departments. It’s always OK to ask lots of questions to make sure that when they talk about a product weight they ‘re talking about the Net weight rather than the weight of all product and packaging on a pallet or that arcane tax-deductible weight the Accounts department uses. Asking “what do you mean by that?” can also be a great springboard into getting even more info that can flesh out your understanding of the system.

A final hurdle that needs to be conquered is the difference between what you want to say, what you think you’ve said and what you’ve actually said in your proposal documents. Despite your best understanding of the solution you need to go through a similar process of filtering out the cruft in your own writing. Making sure your intentions and written word line up can be the difference between a successful project and a costly one.

I’ve only covered a fraction of what Margaret spoke on last week, but what really stuck out to me was the importance of learning from others. It was remarkable how she was backing up her advice with anecdotes and quotes from people who’ve influenced her throughout her life. There was great humility in how she never claimed her accumulated wisdom as her own.

I wrote this blog post as a tribute to an excellent engineer and an inspiring colleague. I’m trying to take on-board what she’s said and implement it in my own life, and I hope that one day I too can pass on my accumulated wisdom. Perhaps I’ll include some choice quotes from her.