Pragmatic Thinking: Novice vs Expert
Join the DZone community and get the full member experience.Join For Free
Recently I started reading Andy Hunt's fine book "Pragmatic Thinking And Learning." Hunt is notorious for writing books which offer
practical, insightful advice in which developers can apply to their work
on a daily basis. His most famous book is "The Pragmatic Programmer",
widely considered one of the top agile programmer books of all time.
Even after reading the book 7 years ago, I still refer to it a few times
a month. My colleagues and I bring up the "broken window" theory, or
often throw out the phrase "Don't Assume, Prove it," sometimes to the chagrin of the unfamiliar. :)
Pragmatic Thinking and Learning is a different type of book, however. It explores the human mind and how it relates to learning and cognitive thought. To my surprise, it is very well researched and touches on psychology and neuroscience. Hunt brings the concepts home by relating them to the software industry and the toils and travails of an agile developer.
Dreyfus Model: Journey from Novice to Expert
One of the more interesting parts of the book is Hunt's exploration of the Dreyfus Model. He defines the stages a person goes through on the journey from novice to expert, regardless of the field of study or activity. These are summarized below:
- Novice - individuals who have little or no evolved experience in a skill area. By evolved, I mean their mode of thinking has not changed over the years. They have have 10 years of experience, but it might be doing something the same way for 10 years (one year of experience, ten times). Novices can be effective with context free rules to follow. They need recipes. They don't know why the rules exists or what to do if the rules don't apply.
- Advanced Beginner - advanced beginners can apply the rules consistently and can recognize the problem context. They want information fast and do not contemplate the big picture. They focus only at the task at hand and are bound to repeatable problems and solutions.
- Competent - competent individuals can troubleshoot problems on their own and can solve problems they have not faced before. They have initiative and are resourceful. However, they still have issues focusing on the correct details and still lack a holistic picture of the problem.
- Proficient - the proficient skill worker needs the big picture. They seek it out and aim to solve the problem with a deeper understanding. They have the ability to not only solve problems, but improve poor situations for the better. Instead of rules to follow, they operate under maxims; heuristics and rules of thumbs that generally apply, but may not always fit. They have enough experience to identify context. They take full advantage of self-reflection and feedback to become more effective in the future.
- Expert - experts are primary sources of knowledge and information in a field. The expert knows the difference between irrelevant details and very important details. Their judgment is logical yet derived from intuition. They are the ones the write the books, articles, travel the circuit with presentations, and are often times the inventor or contributor of the software you use. Experts don't follow rules, they follow intuition and evolved experience.
What is interesting about the Dreyfus model is not just the definition of these stages, but how they apply to the workplace. Especially applicable to the agile developer context, as an individual moves up the Dreyfus model from Novice into the Proficient realm, rules and regulations can actually stifle a developer's productivity.
Hunt actually specifies that ignorance of the Dreyfus model can rob excellent developer's of the expertise and choke their performance.
"But worse than that, by misunderstanding the Dreyfus model, we can rob them of their expertise. It’s actually easy to derail an expert and ruin their performance. All you have to do is force them to follow the rules."
Hunt gives a great analogy of how teams may misapply the model. "Hearding Racehorses and Racing Sheep." This basically means a team can be slowed down by applying rules to proficient level or above members, or a team can burn up by throwing less skilled members into an arena where they cannot handle the load.
To me this concept is the heart of agile. Agile definitely has its structure and framework, i.e., a set of practices and patterns that have proven successful in the past: TDD, Continuous Integration, Iterative Releases, and Refactoring, just to name a few. But Agile methodologies are not prescriptive. It emphasizes continuous improvement. Agile frowns upon context-free rules.
Rules ruin experts.
Obviously this is stark and cannot always apply. Any group has rules, every organization has standards. However the book gives a great overview of the skill model of developers and can give leaders good insight of how to best harness the talent of a team.
Opinions expressed by DZone contributors are their own.