FYI I’ve just appended a small clarification to the end of my recent Pairing and Experts post, clarifying what’s meant by “expert”.
Let’s start this post with a thought experiment. Not in software development, but in playing chess.
Imagine two novice chess players, working as a team. (We’ll assume their opponent is a computer, so it can’t overhear them talk.) Our two novices will benefit greatly from their collaboration. They’ll discuss all their thinking – everything from possible moves, to correcting each others mistakes, to “can you remind me how a knight moves?”. Working together like this they will make fewer mistakes, and generate better moves than each would have done alone.
But what if we paired two chess masters? Scientific research proves that the thinking of experts is different. Much of it happens as automatic pattern recognition rather than conscious reasoning. When a chess master looks at a chess position, (good) possible moves spring to mind immediately. As described in my previous post, these “candidate moves” are generated directly by the brain’s underlying neural network. Neural networks can’t explain their own reasoning, so the master doesn’t consciously know why those moves came to mind. Of course, the moves are indeed based on the master’s long experience, but the mapping from prior experience to current ideas is not open to inspection by the conscious mind.
I was talking to my Mum recently. I mentioned that I’m becoming even more interested in people skills, and she said, “Oh, so you’re interested in management then.”
Actually, no.
If you’re interested in the same things, please comment below or email me (address on About page).
Imagine looking at a dog. You instantly know that it is, indeed, a dog. That’s an incredible feat of pattern recognition, performed almost instantly and without any conscious effort.
Is it really incredible? Yes. It just seems easy because you’ve been doing it effortlessly since about age three. To remind yourself how difficult it actually is, imagine designing an algorithm to recognise dogs. Exactly what would be the rules for distinguishing a small small dog from a large cat? How would you define the category “dog” such that it included Chihuahuas and Great Danes, but not foxes and wolves?
Nobel prize winner Daniel Kahneman uses the dog example to explain the two ways humans think. One way is effortful thought – what we do when consciously thinking about something. The other doesn’t even feel like thinking it all. It’s just effortless automatic perception – like seeing a dog. Much of our brain’s activity is of the automatic kind. Kahneman gives several examples to show the difference:
| Automatic | Effortful |
| Detect that one object is more distant than another | Focus on the voice of a particular person in a crowded and noisy room |
| Detect hostility in a voice | Tell someone your phone number |
| Answer 2 + 2 = ? | Answer 17 x 24 = ? |
| Drive a car on a empty road (unless you are just learning to drive, in which case this belongs in the “effortful” column) | Check the validity of a logical argument |
What does this have to do with expertise? The answer is simply this: expertise involves significant “automatic” thought. For example, you happen to be an expert in recognising dogs. You accomplish that task with no conscious effort whatsoever.
The same applies to activities that we normally associate with “expertise”. Chess masters are a compelling example. When a chess master looks at a board, several strong moves immediately spring to mind. Just like you effortlessly “see” that an animal is a dog, a chess master effortlessly “sees” which moves make sense. This set of “candidate moves” is generated automatically, without conscious effort. Only after the moves spring to mind does the master actually start consciously thinking about them – to decide which of the candidate moves is best.
As Kahneman writes:
[Experts’] intuitive judgements come to mind with the same immediacy as [a child’s] “doggie!"
It may seem hard to believe, that many of our most difficult mental tasks are performed instantly and unconsciously. As Kahneman points out, their very automatic-ness leads us to overlook their importance.
When I was reading his book, I found it helpful to recall the university paper I took in artificial intelligence. There we learned about artificial neural networks. Neural networks implement an approach to computation which is inspired by the structure of the human brain. They are very fast and effective “pattern recognisers” but, having recognised an input as matching a particular pattern, they are completely unable to tell you why it matched the pattern. I.e. they can’t explain their “reasoning”. This exactly matches Kahneman’s description of our automatic thought – it gives you an impression/hunch very quickly, but is unable to tell you why. So:
I wouldn’t dare to suggest that this model is accurate in terms of the underlying biology, but as a software engineer I found it helpful in understanding Kahneman’s work.
Consider two chess players, a novice and a master. The novice relies almost entirely on effortful thought. “How does a knight move?”, “Let me think what would happen if I moved my rook to here…”. But the master makes heavy use of automatic thought. The master’s automatic mind takes care of most of the details that the novice struggles with, leaving the master’s effortful mind free to add value where it is most needed. Consequently the master can produce better decisions in less time.
But how does the novice become a master? How does someone using effortful thought slowly transition to creating (good-quality) automatic thoughts? Through practice. With enough time, and enough examples, your underlying neural network trains itself to recognise the patterns.
Three sources have influenced my thinking about this kind of practice:
I recently noticed how various people debug the large software solution that I’ve been working on for some years. When I need to debug it myself, I don’t get “stuck”. I might not know the cause of the problem, but I always have an idea on what to do next – something that will take me one step closer to finding the problem. Just like experienced players instantly “see” good moves in a chess game; I tend to “see” good moves in the debugging process. A series of such moves, possibly with some backtracking, eventually leads to a solution. But I’ve noticed junior developers are much more likely to get stuck – when faced with a problem they sometimes have trouble generating the “next move”. I’ve also noticed that although I generate moves more successfully than juniors, I seem to expend less conscious effort in doing so.
Of course, this is no excuse for me to take an ego trip – after about 7000 hours with this code base, and a decade’s experience on other systems before it, I darn well should have automatic expertise by now! Junior programmers, or senior ones with less experience of the system at hand, have no choice but to generate fewer moves automatically and fill the gaps with effortful thought. Over time, their balance will gradually shift from effortful to automatic.
The science of expertise has many implications for how we recruit, train and deploy software engineers. In a future post, I intend to explore the implications for pair programming.
Bayes’ Theorem is an important tool when analysing probabilities. It helps us to avoid cognitive traps and make better decisions. However, it is usually presented as something difficult, or even controversial. The typical article on Bayes’ Theorem stresses how difficult it is, and then goes on to bemoan the fact that its not more widely used! In contrast, I argue that Bayes can be explained concisely, memorably, and intuitively.
Read on, and judge for yourself whether I’ve succeeded…
It’s over 7 years since my first post on contracts for agile projects. During the years since I’ve worked almost exclusively on agile projects with fixed scope, learning some real-life lessons along the way.
So here are some of the key points that now I keep in mind when considering estimation, pricing and contracts for agile projects. These points are particularly relevant when customers have asked for fixed price and fixed scope.
Continue reading “Estimation Summary for Agile Projects – Nov 2011″
Alistair Cockburn wrote
Agile development calls for a certain amount of ambiguity and flux in the project. Not everyone enjoys ambiguity and flux. I would suggest that most people don’t.
A very good point. I think this affects some agile implementations – causing them to back away from being really agile, into a no-man’s-land between agile and waterfall.
Personally, I prefer the honest ambiguity of agile to the Clayton’s certainty of waterfall. Software development is risky. Customers and suppliers do learn during the project. Users do give better feedback from trying software than reading documents. To pretend otherwise may feel safer in the short term, but it disappoints in the long run.
I’m reading the book “Crucial Conversations: Tools for Talking when the Stakes are High”. It’s absolutely excellent. And not just for conversations when the stakes are high – but also when the stakes are rather more mundane, such as your typical day-to-day business meeting. I’ve been consciously trying to apply the principles from the book for a while now, and I’ve found that meetings seem much more enjoyable.
The key principle of the book is that conversations work best when everyone is able to “add their meaning to the pool”. I.e. to share what’s on their mind. Conversely, conversations work poorly when people withhold information and viewpoints:
When people purposefully withhold meaning from one another, individually smart people can do collectively stupid things.
Therefore, successful dialog depends on two learnable skills: (a) helping other people to share what’s on their mind, and (b) being able to share what’s on your mind even in difficult situations. I’d like to share a recent example of the latter…
Our (excellent) manager was describing a change to our processes. I hated the idea. It seemed bureaucratic, time-consuming and just plain wrong. As he said how much “we need to do it”, I found myself giving up. My instinct was to withdraw from the conversation. If he was so sure, what point was there in discussing it? He wasn’t actually asking for our opinions. And besides, everyone else seemed to agree. At least, they were sitting there nodding.
But just in that moment of giving up, I caught myself. Sharing meaning is good, right? Yes! And even fun? Yes, as I have discovered. So in that moment I decided to take the enjoyable, productive route, instead of the grumpy silent one. I said something like this:
I feel a bit concerned about the cost of doing this. On <project X> we deliberately avoided gathering this data, and it was fine. We used high-level figures, instead of the detailed breakdown we’re talking about here, and …” I went on to briefly expand on our experience on <project X>.
Instead of giving up, I had managed to share “my meaning” with the group. It wasn’t so hard. It didn’t seem like I’d offended anybody, and I felt much better within myself for having shared.
(Incidentally, talking along the lines of “I feel concerned about…” is a useful collaboration technique that I’ve picked up along the way. It works much better, and is more honest and more informative, than bluntly saying “I don’t like that”. Another handy technique is to talk in terms of concrete stories, as I did about <project X>. Both these techniques deserve blog posts of their own one day…)
So did it work? Did adding my meaning to the pool actually advance the discussion? Yes it did. The boss replied with a clarification of his underlying goals. Which was great, because then we were able to think about all possible ways to meet that goal – instead of just debating between his original plan and my suggested alternative. We haven’t finalised the decision yet, but it looks like we’re going to end up with something better than either of us had imagined.
You can now subscribe to email updates from this blog. This should be handy if you prefer email to RSS. Just go to the new Subscribe page on the menu bar.
PS If you spot any problems with the email subscription, please let me know. I’ve never used this particular email plug-in before, so I don’t know how it will work out.
Humans are bad at understanding large numbers. Our education system successfully trains us to understand the relative magnitudes of small numbers, but for larger numbers we tend to fall back on an intuitive logarithmic scale. So we underestimate the real difference between, say, a million and a billion.
Here’s a wee table I put together, to help with visualising large numbers. The table is based on the thickness of a New Zealand $1 coin.
| Number | Length | |
| $1k | 10^3 | person |
| $1 million | 10^6 | airport runway |
| $1 billion | 10^9 | India |
| $1 trillion | 10^12 | Moon * 8 |
So to visualise the difference between a thousand, a million and a billion, you can say: “person, runaway, India”.
Footnotes Nov 2011:
1. Here’s an amazing visualisation of dollar values at various scales
2. Further to the billion-coins-in-India example: what if we lined up a billion people, instead of a billion coins? That’s approximately the actual population of India. To get a line the same length as the billion coins, we’d have to ask the people to stand about 500-abreast. I.e. the population of India could stretch from the north to the south of the country, if they formed a long, skinny loosely-packed crowd approximately 500m wide.
3. A similar crowd in New Zealand, with the entire population of 4 million stretching the full length of the country, would be only 2 or 3 people wide – in part because the country is sparsely populated, and in part because it’s a long skinny country.
Jan 2012:
4. The number of stars in the observable universe is estimated at 7 x 1022. Given the world population, that’s 10 trillion stars per person – which equates to one stack of coins, reaching most of the way to Venus, for every person alive today.