the three levels of learning
Tue, Jul 17, 2007
I’ve been reading about the three levels of learning and understanding, not just in the context of agile software development but how they also apply to other aspects of human development, such as Shu Ha Ri of Aikido. Reading about the different levels, I can relate to this quite well, especially when I started working in the XMPP domain, which I’d never been near before. I thought I’d try out my understanding of the text by attempting to explain the three levels, as suggested by the book.
is the the most basic. You’re starting from a clean sheet and you have no idea how the domain works. You are in need of instruction, which, in open source systems, is all too often lacking or patchy at best. At lot of open source systems are aimed at Level 2 practitioners, of whom we’ll get to in a minute. How many times have you moved into a new application domain, for example, Sakai and wondered how on earth does all this work. The Sakai documentation is well spread out and a lot of it is hard to decipher and the newer parts are not documented at all. Sakai expects you to be familiar with other domains, which have nothing to do with “Sakai the approach to learning” such as dependency injection and other Spring Framework ideas. At this level, all you want is a concrete example of how to do something, e.g. how to write and deploy a tool. And here you come up against another problem for Level 1 people. The fact that a lot of tutorials are written for the wrong audience. They’re mostly written for Level 2 people. People who have mastered the basics and are ready to branch out, to learn different ways of doing the same thing. My Sakai tool Really Simple Tutorial is an example of a tutorial intended for a Level 1 audience. It states that, if you follow these steps, it will work. At Level 1 you don’t know why it works. You just know that if you follow the instructions, it will work. Everything is longhand in Level 1 communication. There are no shortcuts of shared experience. Everything is raw and unpackaged. No patterns emerge and if you are confronted with another way of doing the same thing, you get confused and disillusioned. Which one do you use? Why is that guy using that way? Is the way I have learned wrong? Is it out of date? Should I learn the other guy’s way? To dispel these fears and start to understand the new domain, we have to move to Level 2.
is where we can comfortably work with multiple ways of doing the same thing. Our circle of technical contacts widens and our experience builds over many project iterations. We pick up new ways of working within the domain and we save state in our professional lives, marking them with concepts along the way. Concepts that encapsulate the rote and tedium of Level 1 learning. We communicate in shorthand. We use UML to express our ideas. We refer to well known concepts and paradigms but at the same time, we’re conscious of using a particular development process to achieve our project goals. We know we are “doing XP”. We know that what we are doing is called “pair programming”. We’ve taken all the Level 1 learning that we’ve done, packaged up individual methods into wider concepts, tagged them with well understood names and now use them as communication shortcuts. We’re still working in the new domain but we’re aware of what we are doing. If you asked someone at Level 2 what they were doing, you’d get an answer along the lines of “we’re upgrading the existing chat system of the Sakai VLE, using pair programming, TDD and XP”. Level 2 practitioners have new concepts and terms to throw around. They sound good to talk about and they give confidence that we are getting better at what we do.
is the “nirvana” of software engineering. Level 3 practitioners understand their domain so well, they can, when asked, give a pretty good estimate of whether what is being proposed will work. Why it will work and why it might not. They don’t have heuristics on the wall to guide them in this. They just “know”. They know from past experience of multiple domains. Experience of communicating with existing Level 2 people. They not only know how the domain works, they know how their political environment works too. At this level, no-one mentions XP or TDD. They just do it. If a software project management researcher came and sat next to a Level 3 person, they would identify the core concepts of TDD, XP etc that they are doing but ask the Level 3 bod why they do it, they would just reply “because it works”. This is what the Level 1 person says too. “Because it works” but at Level 1, it only works because they’ve been told it works. At level 3, it works because they’ve tried it for years and it works all the time, with modifications here and there, depending on the political and technical climate prevalent during that project.