23 March 2010
At DevWeek last Tuesday, I saw Kevlin Henney deliver a talk based on the O'Reilly book '97 Things Every Programmer Should Know', which Henney edited.
He spoke about how the book came about: it's 97 things (and not 98 or 96) because that's the title of the series, but it's also consistent with how the book was crowdsourced, with leading programmers writing short essays on ideas. "If you want to get people to propose something, you want something that works on a page count basis,” said Henney. "If the page count [for each contribution] is too high, you exclude certain people from writing. A lot of people are happy writing blog length pieces of 400 words. Once you're talking about 1500 words, the blank page scares people off and you just get the professionals. You don't get a genuine cross-section of people.” He said 100 pages would be a pamphlet, 300 would be too much, but 200 is just right, which would be about 100 ideas covered in about 2 pages each.
If you're thinking about a similar crowd-sourced project, it's worth working from the book length back to the contribution length, considering who you want to involve and how much they can write.
What I really wanted to share from his talk, though, were a few ideas that I thought were as applicable to writers as they are to programmers.
His first thing programmers (and writers?) should know, is to do lots of deliberate practice. "You might meet someone and they say they have 15 years' experience,” said Henney. "That's impressive. But then you realise that what they have is one year's experience fifteen times, or six months thirty times. They've flatlined.” He said that he can juggle and play guitar, but that he hasn't improved much in 20 years because he doesn't spend time practising. How do you know when you're practising? Henney defined practice as being when the sole goal is to master the task, rather than to complete the task itself. Writing exercises can clearly play a key role here.
The second piece of advice he shared was to step away from the keyboard, so that you can let the ideas form properly. This is always worth remembering. Who has all their best ideas sat at a keyboard? Few people, I'd guess. Those writing in a corporate environment especially struggle with this, I believe, because taking time out to think is indistinguishable from skiving to the untrained eye, so people often feel they can't actually step away from the keyboard, even when they need a break to crack a writing problem.
The third piece of advice was to know the difference between a time estimate, a target and a commitment. In corporate writing environments, there is often negotiation around these when the writer says how long something will take (the estimate), the client or manager tells him or her to halve it (the target) and they agree a date somewhere in the middle (the commitment). The problem with this is that the estimate of how long the work will take hasn't changed, which means something has to give in the content or quality in order to meet the commitment. Trouble results when people confuse estimates and commitments.
The rest of the talk was more technical, and it would be too much of a stretch to relate it to writing. If you are interested in programming, the book content is available online here. Some of the contributions are superbly well written as well. If you can understand programmer speak, the book is worth dipping into just to appreciate the clarity of thought. If you prefer print, the book is also available at Amazon.