QCon Deliberate Practice video

Videos are like buses. None for ages then two come along at once. I did this talk, on Deliberate Practice at the QCon conference in London earlier in the year (it's only just been put online). It's an extension of my 97 Things Every Programmer Should Know entry.

In the brain of me

Here's a video of the SkillsMatter talk I did on Thursday, titled "Stuff I'm starting to know now that I really wish I'd known 20 years ago". Its loosely based on the theme of Making The Invisible More Visible, one of my entries from the book, 97 Things Every Programmer Should Know. I completely botched what I was trying to say about courage. What I was trying to say was that courage is not the absence of fear.

My other SkillsMatter talk was based on Do More Deliberate Practice my other entry in the 97 Things Book.

This was the first run of quite a lot of new material so I was quite nervous, but I felt most of it went very well. Here's some of the feedback.

• Fun, informative, useful
• An interesting brain dump
• Entertaining and enlightening
• Very good. Thoughtful and interesting
• Great content - very interesting
• Great laid back presentation
• Interesting ideas and great presentation to go with it
• Well planned presentation, not just your standard powerpoint
• Very good talk. Inspiring
• Very interactive and well explained
• Clear explanations, good analogies, funny
• Fantastic
• Very good. Passionate speaker. Good insights

Test-gunpowder-pudding driven development

I was rereading chapter 3, Systems and Illusion in Jerry Weinberg's excellent An Introduction to General Systems Thinking yesterday. On page 56-57 Jerry writes:

If I say: "The exception proves the rule" in front of a large class, there will be a division in understanding... Some will believe I have uttered nonsense, while others will understand "The exception puts the rule to the test"

I've read the book four times. I'm a slow learner but this time something clicked and I immediately understood the earlier passage:

...the exception does not prove the rule, it teaches it.

Jerry goes on:

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

I was struck by two thoughts when I read this. One was the parallel with testing. Of a test as a "proof". The other was the word original. I realized that when I hear the word "proof" I have a strong association with its noun meaning rather than its verb meaning. I tend to think of a proof as a finished proof that completely proves something. It's the noun-verb thing I've blogged about before. I wondered if there were any old dictionaries online so I could get a feel for how the generally accepted meaning of the word proof might have changed over time. There is. http://machaut.uchicago.edu/websters has two Webster's dictionaries. The 1828 dictionary came back with:

Proof [noun] 1. Trial; essay; experiment; any effort, process or operation that ascertains truth or fact. Thus the quality of spirit is ascertained by proof; the strength of gun-powder, ...

The 1913 one came back with:

Proof [noun] 1. Any effort, process, or operation designed to establish or discover a fact or truth; an act of testing; a test; a trial.

and a modern dictionary http://www.thefreedictionary.com/proof said:

Proof [noun]. 1. The evidence or argument that compels the mind to accept an assertion as true.

I find the difference fascinating. The 1828 and the 1913 definitions define the noun as the process whereas the modern one defines the noun as the evidence resulting from the process.

Jerry continues:

We retain this meaning in the "proofs" of printing and photography, in the "proof" of whiskey, and in "the proof of the pudding." Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities to take on an additional sense: "To establish, to demonstrate, or to show truth or genuineness."

At first I didn't understand the bit about "eliminating the negative possibilities". I think it's partly to do with my ITA spelling at school. But I am persistant. Slowly it came to me. The word that did it for me in...

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

...was the word if. To determine if they are of satisfactory quality. The proof was an act. There was the possibility of failure.

I started thinking about the word proof a bit more. I googled the phrase "the proof of the pudding". If you think this phrase is pretty meaningless then you're right - it's a shortened version of:

The proof of the pudding is in the eating.

Again it's about the possibility of failure. It reminds me of the scene in the film The Cat in the Hat (another film Patrick and I love watching) where the Cat has just made some cupcakes (with the amazing kupcake-inator). He tries one and says:

"Yeuch. They're horrible. Who want's some?"

I love that line. I also googled the word proof as related to alcohol content. The history behind the phrase is just wonderful. In the 18th century spirits were graded with gunpowder. Imagine you're buying some spirits. How would you know if an unscrupulous merchant had watered it down? You couldn't tell just by looking. What they did was pour a sample of the solution onto a pinch of gunpowder. If the wet gunpowder could still be ignited then the solution had proved itself. Don't you just love that?

So let's hear it for pudding and for spirits and for gunpowder and for tests. And for the possibility of failure.

do more deliberate practice

This is one of my entries in 97 Things Every Programmer Should Know

Deliberate practice is not simply performing a task. If you ask yourself "Why am I performing this task?" and your answer is "To complete the task," then you're not doing deliberate practice.

You do deliberate practice to improve your ability to perform a task. It's about skill and technique. Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task. It means repeating the repetition. Slowly, over and over again. Until you achieve your desired level of mastery. You do deliberate practice to master the task not to complete the task.

The principal aim of paid development is to finish a product whereas the principal aim of deliberate practice is to improve your performance. They are not the same. Ask yourself, how much of your time do you spend developing someone else's product? How much developing yourself?

How much deliberate practice does it take to acquire expertise?

• Peter Norvig writes that "It may be that 10,000 hours [...] is the magic number."
• In Leading Lean Software Development Mary Poppendieck notes that "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts."

The expertise arrives gradually over time — not all at once in the 10,000th hour! Nevertheless, 10,000 hours is a lot: about 20 hours per week for 10 years. Given this level of commitment you might be worrying that you're just not expert material. You are. Greatness is largely a matter of conscious choice. Your choice. Research over the last two decades has shown the main factor in acquiring expertise is time spent doing deliberate practice. Innate ability is not the main factor.

• Mary: "There is broad consensus among researchers of expert performance that inborn talent does not account for much more than a threshold; you have to have a minimum amount of natural ability to get started in a sport or profession. After that, the people who excel are the ones who work the hardest."

There is little point deliberately practicing something you are already an expert at. Deliberate practice means practicing something you are not good at.

• Peter: "The key [to developing expertise] is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes."
• Mary: "Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at. So it's not necessarily fun."

Deliberate practice is about learning. About learning that changes you; learning that changes your behavior. Good luck.


This blog entry is "syndicated" in Croatia on agile.hr

97 things every programmer should know

is an excellent book edited by Kevlin Henney (isbn 978-0-596-80948-5). As usual I'm going to quote from a few pages:

Pay off technical debt as soon as possible. It would be imprudent to do otherwise. Seb Rose

Users don't think like programmers. Giles Colborne

Comment what the code cannot say, not simply what it does not say. Kevlin Henney

Deliberate practice is not simply performing a task. If you ask yourself "Why am I performing this task?" and your answer is "To complete the task," then you're not doing deliberate practice. Jon Jagger

the Golden Rule of API Design: It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. Michael Feathers

Professional programming is usually not like running hard for a few kilometres, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. Olve Maudal

What are you working on right now? Is it all needed? Pete Goodliffe

By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Johannes Brodwall

An estimate is an approximate calculation or judgement of the value, number, quantity, or extent of something… A target is a statement of a desirable business objective… A commitment is a promise to deliver specified functionality at a certain level of quality by a certain date or event… Giovanni Asproni

If your project is apparently on track, and one week later it's six months late, you have problems - the biggest of which is probably not that it's six months late, but the invisibility force fields powerful enough to hide six months of lateness! Lack of visible progress is synonymous with lack of progress. Jon Jagger

Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard. Burt Hufnagel

The Singleton Pattern… What's not to like about this classic design pattern? Quite a lot, it turns out. Sam Saariste

Hotel room to train carriage

Appeared in the ACCU magazine CVu, Vol 22, January 2011

Paul has asked me to write something for CVu. I don't have a clear idea of what to write about so I thought instead I would just write about stuff I'm doing. Tonight I'm currently sat in a hotel room in Langley (Berks) after a thoroughly excellent day at a client's site. I've been teaching day one of my C Foundation course. John and Ed suggested some ways the slides, and the words I use to describe the slides, could be improved. So the first thing I've been doing is making some mods to the slides. The first was a simple int to pointer conversion where I initialised an int pointer with the hex integer 0xBEEF. I chose 0xBEEF because it spells a word but didn't think about alignment. 0xBEEF is an odd integer number and the address of an integer is likely to be, at the very least, even. The second was something I said. In the chapter about pointers I said that an invalid pointer doesn't have to be dereferenced for bad things to happen. That's too strong. You only need to think about the free() function to realise that. After you've called free(ptr) then ptr no longer points to an object but as long as you don't dereference ptr you'll be ok. What I should have said is that when you do pointer arithmetic any sub-expressions must always be valid.

Something I try to do regularly is to examine what happened during my day and to learn from it. A sort of retrospective. So I'm looking at the C course mods and wondering what I can learn from them. I'm wondering, in the first example, why I chose 0xBEEF in the first place. Choosing a hex number that spells an english word is overly clever. Overly cute. So now I'm thinking I'd be better off choosing a hex number that doesn't remotely even look like a word. One that would align correctly. I'm struck but how hard it is to avoid being overly clever. By how hard it is to recognise and take into account context. From the second example, I'm reminded how hard it is to say clearly what I'm thinking. Or rather, how difficult it is to have sufficient clarity in my thinking that the words are naturally clear.

As well as learning from the day's mistakes it's also important to think about what went well. I recently did a "60 minutes in the brain of" presentation for SkillsMatter London on deliberate practice (the topic of one of my entries in Kevin's 97 Things Every Programmer Should Know). SkillsMatter videod the talk and I've watched it a couple of times. Watching yourself on video is a tremendously valuable thing. It allows you to see yourself how others see you. Not how you see yourself. For example, something I noticed was a tendency I have to say "ok?" rhetorically at the end of a sentence. Ok? Doing that once or twice is fine but I did it perhaps a dozen times. It was almost becoming a tick. So one of my tasks today was to try not to say "ok?" at the end of my sentences. It's hard to know if I achieved that but I at least feel I didn't say it so often it became a noticeable tick. And I recall a couple of times where I was conscious I had not ended the sentence with "ok?" when previously I might have. But, interestingly, as I write this, I'm thinking how can I know? Perhaps I'm still doing it but don't realise because I can't see myself. So I'm wondering if, tomorrow, I will explicitly ask the guys on the course to tell me if I do it. I think I will. I'm reminded of the line from Robert Burns's Poem To a Louse, "To see oursels as others see is!". I remember Jerry Weinberg mentioning the connection in one of his books. And I notice bagpipe music is playing on my iTunes as I write now. I wonder if my subconscious made the scottish connection? It's the Skye Boat Song (Speed Bonny Boat). My mother used to sing that to me as a bedtime lullaby when I was a small boy.

It's now the next day. I'm on a train heading home. I'm reading some of Weinberg on Writing by Jerry Weinberg. I always carry a book. Usually three. I try to read a lot. Craig Larman once said to me that one of the main things that marks a consultant as a consultant is they read a lot. I have an odd reading habit. I don't read one book from start to finish before starting another book. Instead I read a small chunk from one book, and then put it down, and read another small chunk from another book. I often have about 20 books all partly read. Today the other two are A Little Book of f-Laws by Russell Ackoff and Herbert Addison, and Culture Against Man by Jules Henry. I don't have any fixed rules about switching from one book to another. I just try to sense when it feels right. And I don't have any fixed rules about which books I pop into my travel bags either. It may sound strange but I am trying to cultivate by subconscious so again I just try to sense what feels right. As I'm reading I highlight text that speaks to me. For example, in Jerry's book I've highlighted the following:

• A trigger is a small amount of input energy that sets off a large amount of output energy.

  That caught my interest. I recall Jerry discussing triggers in some of his other books. So I've made a note to reread what he said about triggers there in the light of that quote. An actual note that is - I also always carry a pen and paper.

• Raise your typing speed by ten words per minute. This will give you an extra six hundred words for every hour you work. If you work an hour a day, two hundred days a year, you'll type an extra 120,000 words - a couple of books' worth.

  That's quite illuminating.

• You know, there would be no problem raising kids if only you could throw away the first one.

  That made me laugh.

• Writer's block is not a disorder in you, the writer. It's a deficiency in your writing methods - the mythology you've swallowed about how works get written - what my friend and sometime coauthor Tom Gilb called your 'mythology'.

It took me a while to find that last one. I knew I had read it but I couldn't find it. I searched in the chapter I read most recently. No luck. I flicked through looking at the marked passages. No luck. Then I stopped and thought about what to do next. (It's almost always better than repeating a failed approach.) I wondered if Tom Gilb had an entry in the index. And he did. And it was exactly the passage I remembered. It was on page 19, not anywhere near the chapter I was reading most recently. And it was a passage I'd marked as I read it. And yet I looked at the marked passages trying to find it. I clearly missed it. That's reminded me that I have a tendency to only see something when searching for it if matches my pre-formed idea of what it will look like. My lovely wife Natalie tells me that's a typical male trait. That last snippet about Tom Gilb has sparked something in my mind. Partly I'm attracted to the word myth because one of my favourite corny jokes is the old chestnut "what is a myth?" the answer being "a female moth". But it's more than that. I think it's because my subconscious is connecting the word mythology with the word methodology. That's an interesting connection. A Mythodology perhaps?

Anway, when I've finished reading a book I copy the bits I highlighted into my personal wiki. Then I copy the dozen or so highlights that speak to me the loudest into a small book "review" snippet for my blog site 'Less Code, More Software'. Then I put the book onto a pile to take to the next accu conference to raise some money for charity. We'll be coming into Taunton any moment now so I'm going to sign off.

It helps to know what success looks like

On a plane when the cabin crew perform their emergency demonstration they don't merely read out the information over the tannoy. No. The cabin crew stand where you can see them. They act. You see them pulling an oxygen mask towards themselves. You see them putting it over their heads. If they're good you see them slowly turning their heads side to side so you can see the elastic at the sides of their heads.

One of my entries in the book 97 Things Every Programmer Should Know is called Make the Invisible More Visible. Visibility is an important aspect of practice and learning. It relates to feedback. You evaluate feedback in the context of your intention - of what you are trying to accomplish. You need a clear idea of where you are trying to get to, of what success will look like when you get there.

In the brain of Jon Jagger - Deliberate practice

Here's a video (and slides) of my SkillsMatter Deliberate practice talk. This is a much extended version of the 97 Things lightning talk I did at Javazone recently. I've been known to break cameras and mirrors in the past so they wisely filmed it in very low light... :-}

JavaZone 2010: 97 Things Lightning Talk - Do more deliberate practice

Here's a video of the lightning talk - Do more deliberate practice (one of my entries in the book 97 Things Every Programmer Should Know) I did at the recent Javazone conference. It's about how deliberate practice relates to agility.

Kata Practice

One of my contributions to the 97 Things Every Programmer Should Know is all about deliberate practice. Pretty much the only form of software practice I've ever seen are the various Katas developers sometimes work on in coding dojos. The Bowling Game Kata for example. However, while Katas are definitely a form of practice the ones I've seen people perform have not been very deliberate; I never get the sense much deliberation is going on.

Quoting Peter Norvig again:

The key [to developing expertise] is deliberative practice: not just doing it again and again but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes.

I'm not convinced that the Katas I've seen developers participate in have been beyond their current abilities. I get the strong feeling the participants are there mostly to have fun. Be that as it may I'm absolutely certain that I've never seen any evidence of conscious analyzing of performance during the kata, and certainly no repetition of whole kata again. I mention this because I think these coding exercises have been mislabeled. I think they are much closer to being Randori than Kata.

Wikipedia says Randori is "a term used in Japanese martial arts to describe free-style practice or sparring, sometimes with multiple attackers". That's what I see in coding dojos.

In contrast Wikipedia says that Kata is "a Japanese word describing detailed pre-arranged choreographed patterns of movements practiced either solo or in pairs". That certainly matches my experience of performing Karate Kata - of repeating the exact same Kata over and over again - of moving slowly and, excuse me if I'm labouring the point, deliberately. You might argue that in the Bowling Game Kata the choice of Kata is pre-arranged. That's true but it's not the point. That's focusing on the static rather than the dynamic. The point of a Kata is its pre-arranged movements.

I think if I saw a true Kata syle practice I'd recognise it because of...

• its short duration
• a restriction on freedom of movement
• a marked slowing down of normal development speed
• a definite period assigned to reflection afterwards
• a cycle of repeating the exact same Kata again and again

For example a true Kata style practice might be only 10 minutes long, take place in a environment/ide that refused to give you edit rights to the code files until you'd written a failing test, that delayed the results of each run-the-tests event for 10 seconds or so. I'm planning to incorporate some of these ideas in the next run of the Average Time To Green Game.

2 Things Every Programmer Should Know

Are my contributions to the forthcoming book 97 Things Every Programmer Should Know by O'Reilly. I hope they're accepted.

• Do Lots of Deliberate Practice, and
• Make the Invisible More Visible.

I've been thinking about practice a lot recently. The Average/Mean Time To/Since Green Game has a large element of practice designed into it. In his excellent book The Fifth Discipline, Peter Senge writes:

The total absence of meaningful practice or rehearsal is probably the predominant factor that keeps most management teams from being effective learning units.