I received a new book a few days ago: Pragmatic Thinking & Learning, by Andy Hunt, one of the authors of Pragmatic Programmer. The book is all about the way we think, and how our brain works in R-mode (rich mode) and L-mode (linear mode), the advantages of getting your R-mode in action and so on. Lots of interesting stuff and totally programmer oriented, so it's very easy to read.

But I'm not going to talk about the whole book (this is not a book review after all) but only focus on something which I found extremely interesting: expertise levels. Chapter 2 talks about the different expertise levels on any area: from novice to expert. Andy explains the Dreyfus Model which explains the different expertise levels by skill.

The basic skill levels are: novice, advanced beginner, competent, proficient and expert. And what is really interesting is how at each level we react differently to the same things. Andy gives a great example: when you're a novice cooking and someone tells you "just cook it until it's well done", you're in big trouble! What "until well done" means? (I've found myself on that situation several times and that's probably why I loved the sample). For the expert it is clear: he knows what it means based on his previous experience, and knows done will take longer or shorter depending on several conditions, and will react accordingly. But, on the other hand, the novice needs clear rules. He doesn't want to bother with a lot of overwhelming stuff at the same time, if only someone could tell him the number of minutes to wait... Of course, things are not that simple, and the expert knows it's not only a matter of waiting a certain fixed number of minutes, but this information would greatly help the novice. Novices need recipes, clear rules to follow. Following the rules they'll advance and, step by step, they'll be discovering new information and maybe one day they won't need the rules anymore. The expert can write down a recipe with clear instructions, even the number of minutes to wait at each stage. Of course, he wouldn't ever follow his own instructions since he would under perform because there's much more to consider than a simple set of rules.

There's also a very interesting graphic describing general expertise distribution.

 

I was shocked to see that for most of us, no matter the time you spend on a given subject, advanced beginner will be our top level, and only a few will climb the ladder higher. Andy states that for a lot of people 10 years of experience (the minimum average time to become an expert) is only 1 year of experience repeated 9 times, since they won't make any progress.

The book continues talking about ways to climb the ladder and make the best possible use of our brain, but know I'm more interested in the implications of the previous statements.

First (and again this is borrowed from Andy), the methods we apply at work have to be tuned to the different levels of team players. Agile methods, the 21th century panacea, are for experts, so be careful when applied to novices. We've all heard that before probably, but it is very (very) easy to forget when we try to democratize our team, with nasty results.

And then, what about considering all the previous to design new software?

Let me explain it a little bit more: sometimes we write software which is really easy to teach to experts (for instance). They get the concepts rapidly (they already have the background) and jump into the details. They know what to look for, so they only need to find the actual implementations on your software. If you move to a new word processor you know you've to find how to put your text in bold, how to copy and paste, how to format paragraphs and so on. So the application can be better or worse but you know what you're looking for, it's just a matter of finding it.

Of course it is a whole different story when you're a newbie: you don't even know what to look for.

I see myself in this situation on a daily basis since I develop a version control system. For experts it is really easy to perform branching and merging with Plastic since they know what to look for, and they can do it in only a few clicks. But for a newcomer who doesn't master any of these concepts it is not that easy. Why should he branch in the first place? What's all this fuzz about merging? Why do you need smart branches?

Let's focus on the user interface: if we adapt the UI so it is good for experts, probably most of the novices will be lost. And the opposite is also true: let's code a number of built-in rules so we can guide the novices step by step, teaching how to work as they make progress, suggest what to do at each step, even forcing a well-known working pattern which is good for them (even if they don't know). The system would act as a teacher until the user grows up and can make his own decisions (sounds familiar?). Of course, experts will hate it since they'll be over constrained. There will be different ways to act at each step, and an expert would probably follow another path. He'll be annoyed by the over simplified UI or a step by step tutorial.

How can we balance between novices and experts? And, what's even more complicated, how can we adapt our software to the 5 different experience levels?

I think the answer is simple: there's no simple way to build a one size fits all solution if you want to target all the steps in the expertise ladder. Probably you can find a common solution for the first three levels, or the three upper ones, but I doubt you can share everything with only small modifications when you're targeting the full ladder. So, maybe we need some sort of multi-level UI which will provide completely different options (ok, based on the same core, it's the same package after all) to different skill sets. A good modular design, a well structured and detached UI and logic layers will be key for it. And then let your UI designers focus on the specific problems, give them freedom to find the best solution for each level, and adapt your software to the target audience as much as possible, even targeting each level separately.

This multi-level UI idea is not new but it's something I'd like to try myself at work in order to create self-teaching software (because, who read the manuals after all? :-P)