Mark Needham

Thoughts on Software Development

Archive for the ‘dreyfus-model’ tag

Learning cycles at an overall project level

without comments

I was looking back over a post I wrote a couple of years ago where I described some learning cycles that I’d noticed myself going through with respect to code and although at the time I was thinking of those cycles in terms of code I think they are applicable at a project level as well.

The cycles I described were as follows:

  1. Don’t know what is good and what’s bad
  2. Learn what’s good and what’s bad but don’t know how to fix something that’s bad
  3. Learn how to make something that’s bad good

I think I’ve followed similar cycles with respect to how an overall project is run.

To start with I didn’t really know what it was that made a project run with an agile mindset different to anything I’d seen previously so I spent a lot of time observing the approaches my colleagues used, the processes they tried to drive and generally trying to understand what made a project tick.

Having worked on quite a few projects and seen similar underlying concepts working despite differing contexts I started to notice that the situations coming up were often the same or very similar to ones that I’d seen before.

At this stage I was more convinced that some of the approaches I’d already learnt could be useful but often deferred to more experienced colleagues or suggested improvements and relied on them to help drive them.

When I worked with Dermot he pointed out that the next step was to now be the one who can drive the changes that I want to see rather than relying on someone else to do it.

I’ve been trying to do that more recently and it’s not all that different to the way that I already try and influence the way that code is designed except it covers a wider spectrum of situations.

Books like ‘Fearless Change’ and ‘Agile Coaching‘ certainly have good tips for how to influence change but I find that more often than not I only really understand how to do something after I’ve made a complete mess of it the first time around.

I guess the downside of trying to influence situations more is that you put yourself in a position to be shot down so perseverance and knowing when to push and when to back off seem to be skills that will be particularly useful.

Written by Mark Needham

September 20th, 2010 at 6:56 pm

Posted in Learning

Tagged with ,

Dreyfus Model: More thoughts

with 6 comments

Since we discussed the Dreyfus Model in book club a few weeks ago I’ve noticed that I’m more aware of my own level of skill at different tasks and references to the model appear more frequent at least amongst my colleagues.

These are some of the things I’ve been thinking about:

How do we use the model?

Alan Skorks has an interesting post where he discusses the role of the Dreyfus Model in helping to build software development expertise concluding that it doesn’t help very much in developing expertise within a team.

In Pragmatic Learning and Thinking Andy Hunt suggested that one way to make use of the Dreyfus Model is to analyse the skill level of people that we interact with and then adjust the way we present information to them accordingly which I think is a good idea but requires a reasonable amount of skill to do.

I’ve found that it’s actually quite revealing to just analyse your own level of skill and I hadn’t realised how many things I am a novice at and just rely on a series of steps/instructions to make any progress and get quite frustrated when one of those steps doesn’t work because I have don’t yet have the ability to problem solve effectively in that area.

I had an example of this a few weeks when trying to port our code from Subversion to Mercurial using hgsubversion and struggled to work out how to get it to work, in particular with the fact that the process always failed at the same revision with no real indication (that I could understand at least) of why that had happened.

I am a novice with regards to doing this. I was just following the instructions and since I don’t have any knowledge of the hgsubversion code base or even of Python I wasn’t able to progress much further.

In this case though there is an argument that even if we are not skilled at a particular task we still might be able to make use of a higher level of skill with problem solving in general to try and infer why something might not be working as expected.

Recognising which other skills might be useful to us when we are struggling with a new skill is perhaps a skill in itself and in this case Dave was able to do this more effectively than I was by suggesting different ideas to try based on his understanding of what probably happened during the porting process.

This allowed us to progress further even though we weren’t successful in getting it to work for the moment.

It’s ok to be a novice at some things

Having recognised that I am a novice at quite a number of different things I was questioning whether I should be trying to improve in all those areas that I had identified.

Discussing this with some colleagues though we came to the conclusion that there are so many different areas of skill in software development that there’s bound to be areas where we are going to be novice and if we don’t use those skills that frequently perhaps it’s fine that we don’t progress beyond that stage.

For more core technical skills it’s more important to raise our level although I think it might be difficult to identify which skills are important and which less so if we are a novice!

There seems to be potentially some conflict here with Marcus Buckingham’s idea of focusing on your strengths if our strengths aren’t aligned with the most important skills for software development.

On the other hand there are so many different areas of the field that it’s quite likely that something we’re good at will be important.

Experts and intuition

The way that those at the expert level work a bit differently to those at other levels is that they rely mostly on intuition when working out what they need to do but I think that there might be a bit of a trap here in that we assume we are an expert at something if we are unable to explain to someone else how or why we do it.

Although teaching a skill to someone else is a different skill than knowing the skill yourself, I think there is some overlap between them.

I have often found that when you try to explain something to someone else you are forced to really work out what you actually know around this area.

I think we probably learn more from teaching a skill to someone else than via any other learning approach and I currently measure my understanding of something based on whether I can explain it to someone else. If I can’t then I don’t know it as well as I thought.

The inability to explain something might indicate that we are an expert working by intuition but it might also indicate that we aren’t as skilled as we’d like to believe.

Justin Kruger and David Dunning’s paper titled Unskilled and Unaware of it, which discusses how people are liable to overrate their own ability and are even more likely to do this the less skilled they actually are, seems to provide some evidence that this theory might be true.

From my understanding of the Dreyfus model one would need to have gone through the previous levels before reaching the expert level so perhaps the perception of expertise wouldn’t actually happen for a real expert.

Written by Mark Needham

August 10th, 2009 at 8:36 pm

Posted in Learning

Tagged with ,

Book Club: The Dreyfus Model (Stuart and Hubert Dreyfus)

with 2 comments

In our latest book club we discussed the Dreyfus Model, a paper written in 1980 by Stuart and Hubert Dreyfus.

I’ve become quite intrigued by the Dreyfus Model particularly since reading about its applicability to software development in Andy Hunt’s Pragmatic Learning and Thinking and after looking through Pat Kua’s presentation on ‘Climbing the Dreyfus Ladder of Agile Practices‘ I thought it’d be interesting to study the original paper.

These are some of my thoughts and our discussion of the paper:

  • We discussed what actually counts as experience at a skill with regards to the idea that it takes 10,000 hours of practice to become an expert at something, and Cam made an interesting observation that ‘if you don’t have a change of thinking from doing something then you haven’t had an experience‘. I really like this as a barometer to tell whether you’re actually learning something or just reapplying what you already know. I find pair programming is an excellent practice for encouraging this.

    From reading Talent is Overrated I learnt that the important thing is that the tasks you are doing are slightly more difficult than your current ability so that you are always stretching yourself.

  • I’ve learnt that it’s not actually possible to skip the levels on the Dreyfus model when learning a new skill – previously when I’ve looked at it I always thought that it should be possible to do that but from experience

    I think you always need to spend some time at each stage while you are finding your feet and this time can be unbelievably frustrating. I think it’s useful to recognise that this frustration is because you are a novice and don’t have a good way to problem solve yet and that it will get easier as you keep practicing.

    It’s interesting how this can be applied to some of the agile practices because all of them come from a higher level principle that we are trying to achieve but you won’t actually understand that principle until you have done the practice for a certain amount of time. At that stage you have a better understanding of why the practice is useful which allows you to choose when it is useful and when a different approach might be more effective.

  • We discussed whether you need to be a master to be able to teach a skill to people. I don’t think these are correlated and that actually to be able to teach someone the more important thing is your skill at teaching on the Dreyfus model. At school for example I often found that the better teachers were the ones who had the ability to explain things in a way that students could understand rather than being the absolute best at the skill themselves.
  • Dave mentioned that he is frequently asked how he knows a certain skill and has therefore started becoming more aware of how this happens so that he’s able to do this more effectively. I’ve often found that understanding the way that more experienced practitioners think about problems is far more useful than just asking them to solve a problem you’re having trouble with.
  • Before the session we arranged for a few of us to try and come up with the behaviours needed for different skills and where they fitted on the Dreyfus model. There was a unanimous feeling that this was actually really difficult which also suggested that you can have a level of skill at using and understanding the Dreyfus model! I think it would be quite useful to identify the behaviours that you want to acquire so that you have some sort of roadmap for developing your ability at a certain skill but we also discussed the fact that the Dreyfus model is actually very useful as a reflection tool when working out where your ability with a certain skill lies and how you can change that. I think tracking your improvement against the Dreyfus model would be far more effective than a typical performance review.
  • We spoke about beginner’s luck and how we ofen do things much better when we first start doing them as it is pretty much reflective without too much analysis which would potentially ruin our performance. At this stage we are unconsciously incompetent at the skill so we just do it. I think having some success at a skill due to this actually results in motivation to keep on improving and actually improving our skill level.

I think the Dreyfus model in general is a really cool thing to learn about although I found that the way it is presented in Pragmatic Learning and Thinking is more accessible than the original paper. It’s interesting that it was written about nearly 30 years ago and we don’t make use of it as much as we could.

Written by Mark Needham

July 18th, 2009 at 10:40 am

Posted in Book Club

Tagged with ,

Ferengi Programmer and the Dreyfus Model

with 5 comments

I’ve been reading Jeff Atwood’s post regarding Joel’s comments on the podcast about Uncle Bob’s SOLID principles and what struck me as I read through his dislike of having too many rules and guidelines is that there is a misunderstanding of how we should use these rules and I think at the heart of this understanding the Dreyfus Model might clear this up.

To briefly recap the different levels of the Dreyfus Model (you can read more about this in Pragmatic Thinking and Learning)

  • Novice – Little or no experience in a skill area
  • Advanced Beginner – Break way from rules and try some stuff alone. Have difficulty troubleshooting
  • Competent – Develop conceptual models of problem domain & can problem solve
  • Proficient – Try to understand larger conceptual framework around skill. Can reflect on performance and do better next time
  • Expert – Vast range of experience to apply in just the right context

Given these levels at which any person may be at for a given set of skills, as Dhananjay Nene points out someone who is an expert in this area is not going to be referring to a checklist of design guidelines – they have already been past this stage and are at the stage where they can apply the ideas intuitively in the right context.

If you are at a stage where you still need to review your design with respect to the SOLID principles (or other appropriate design principles) – please take your time to apply the principles, learn if you are breaking them, understand the costs of doing so (I would recommend that involve a senior programmer / designer in the process) and then by all means make the best judgement. Principles distilled over time and experience should be adjusted preferably by those who understand the cost and implications of doing so, the rest should strive to reach that state first.

In which case the following statement on Jeff Atwood’s post makes perfect sense:

Like James Bach, I’ve found less and less use for rules in my career. Not because I’m a self-made genius who plays by my own rules, mind you, but because I value the skills, experience, and judgment of my team far more than any static set of rules.

But it shouldn’t be used as a stick to beat the principles because using them as a set of guidelines or rules is still very valuable for someone who is not so far up the Dreyfus Model as Jeff is for this skill.

I still think there is value in re-reading the principles even when you think you have got them ingrained in your mind and don’t need to keep on referring to them to write your code. I have often found that when I end up writing code which is difficult to work with it tends to be because I’ve broken one of the principles without realising that I was doing so.


To summarise I don’t see a problem in following principles/rules when you are new to a skill – in fact I think this is the best way to pick up good practices otherwise you are just guessing.

In order to progress up the Dreyfus Model we need to eventually start questioning the rules and working out when we should and should not apply them.

Leaving the last word to Mr Atwood…

Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substute for thinking critically about your work.

Written by Mark Needham

February 13th, 2009 at 12:01 am

Posted in Learning

Tagged with

Pragmatic Learning and Thinking: Book Review

with 14 comments

The Book

Pragmatic Learning and Thinking by Andy Hunt

The Review

I came across this book when reading a post linking lean to the Dreyfus Model on Dan North’s blog.

I have a keen interest in theories of learning and have completed an NLP Practitioner’s course so the ideas described in the book summary immediately appealed to me.

After coming across the concept of Reading Deliberately in Chapter 6 of the book I decided I should give the SQ3Q approach to reading books its first run out.

I think I did some of the ideas it suggests implicitly but I thought it’d be good to purposely use it. The approach is briefly summarised further down.

I originally intended to buy this book but it wasn’t available before I came to Australia so I got a Beta version from The Pragmatic Programmers website – an idea my colleague recently posted about.

What I wanted to learn

  • Journey from Novice to Expert – How can I use the Dreyfus Model more effectively when learning new skills? Will I learn how to become expert quicker? How can I make use of the Dreyfus model on a day to day basis? Why do some people pick up skills more quickly than others?
  • This Is Your Brain – What things are critical for learning success? How can we best utilise the brain’s design to maximise learning? Is there a difference between how we learn language APIs and design skills?
  • Get In Your Right Mind – What are the L & R modes of the brain?
  • Debug Your Mind – Can you change the way you think? How does the way in which we are taught to think in school limit us?
  • Learn Deliberately – How will the ideas here overlap with Scott Young’s ideas around Holistic Learning? How will NLP theories of learning link to the ideas laid out here? What can I do to master skills more effectively?
  • Gain Experience – How do we keep learning as a key focus in situations where it may not be considered that important? How do we achieve short feedback loops when learning?
  • Manage Focus – Is gathering contextual information around a topic still valuable for learning? I lose focus fairly easily – will I learn how to improve that?
  • Beyond Expertise – What does it mean to be beyond expert in any field?

What I learnt

  • I had heard of the Dreyfus Model before reading this book, but the explanations of it and examples of its application in developing software development skills was especially useful. It has helped me to become more aware of the level I am currently at with skills I use day to day as well as providing pragmatic suggestions on how to improve my level. The ideas around creating continuous improvement by undertaking tasks that are challenging but doable in an environment which provides quick feedback was an idea I have heard of previously but it was good to have it reinforced.
  • Capturing your ideas is one of the early recommendations – I have got in the habit of always carrying around a Moleskine notebook with me since the start of this year. I use it to write down things that I want to learn or read more about at a later stage. When I get the time I go through everything I’ve written down and tick it off. I find this works well because often when pair programming it isn’t productive to go off reading about side topics but equally I don’t want to forget to go and look it up.
  • The idea of the system metaphor for software systems is one which is closely linked to some of the ideas in Domain Driven Design with regards to using clear real life metaphors to represent the way that our system works. I don’t think this is something that has caught on completely just yet but it seems to be covered by such ideas as intention revealing interfaces and by taking an intuitive approach when naming classes and methods.
  • I have long thought that the teaching approach used at universities is completely suboptimal for learning – it is too focused on providing knowledge rather than the ability to solve problems. This is pointed out by the author who does so by questioning the purpose of technology certification programs. He suggests taking a SMART approach to learning – learn something Specific, with Measureable success criteria, make it Achievable, something that is actually Relevant to you or something that you care about, and do all this within a Time box.
  • The author also talks of getting experience in new skills first before learning the theory. I have been trying to take this approach to learning Ruby – we dived straight into the code but often take steps back to ensure that we are using the language properly and not just writing Javaesque Ruby code. When we eventually read about the theory we have a much better context to apply this learning to rather than just reading all the information up front.
  • The SQ3R approach to reading material is something which I have been trying out. To summarise, the approach includes the following steps:
    • Survey – scan the table of contents and chapter summaries
    • Question – note any questions you have
    • Read – read in entirety
    • Recite – Summarise and take notes in your own words
    • Review – Re-read, expand notes, discuss with colleagues

    With this book in particular I found the ‘Survey’ step especially useful – I initially skipped reading 3 of the chapters as they seemed too scientific for me. After reading about this technique I went back to these chapters and became more curious about what I was interested in learning.

  • The idea of linking new information you read about with knowledge you already have using mind maps is something that I first started doing around a year ago. I haven’t done it for a while though and since restarting it a couple of weeks ago I’m noticing more links between things than I did previously and finding learning new information more enjoyable. One interesting point which was made is that it is much more effective when you are drawing the mind map by hand rather than using a software package to draw it. I have never put colours or pictures in my mind maps but this is suggested as another addition to the technique.
  • Test Driven Learning – I really liked the ideas outlined here. One suggestion was that we should try and recall material learnt after 2 minutes, after 2 days, after 2 weeks, after 6 months to ensure we know it well. Other ideas to strengthen the learning process included teaching the concept to a colleague and drawing & re-drawing mind maps. I think writing about something on a blog or similar also helps to clarify understanding.
  • The idea that learning can be fun is one that I found interesting – I have started to come around to this point of view more over the last couple of years having previously only considered learning to be what was done at school. The following quote from the book captures the essence of what is being suggested:

    Working with new material or solving a problem in a playful manner makes it more enjoyable, but it also makes it easier to learn. Don’t be afraid of fun.

  • The author speaks about creating awareness when learning a new skill rather than focusing on what you are doing wrong:

    You want to try to cultivate nonjudgmental awareness: don’t try to
    get it right, but notice when it is wrong. Then act to correct it.

    He also speaks of imagining yourself as being better than you are – i.e. playing the expert. I have read many times that the human mind can’t tell the difference between a real experience and an imagined one so that’s where the logic for this idea comes from. It was actually while reading a book called Mind Games that I first became interested in NLP and then eventually came across this book.

  • In the chapter on managing focus the author speaks of the benefits of meditation – I have never done this as I couldn’t see the benefits of doing so but having read some of the ways that it may be helpful it is something I am going to try out. A type of meditation called Vipassana meditation is detailed.
  • The idea of using TextMate as a Wiki was one which I am now trying out using the Plan Text Wiki TextMate bundle. I currently only keep track of my ideas using MarsEdit, my notepad and Moleskine but this has provided me with a new idea for organising information effectively on my computer
  • The book cites numerous sources for the more scientific information presented. Some of the ones which I have put on my reading list are:

In Summary

I really enjoyed reading this book – there were so many suggestions that really made me think – I’ve tried to cover some of my favourites in my review but there is way more useful information and ideas in this book than what I can do justice to here.

It is a bit scientific in places and I read some of the chapters at the end before some of the more theoretical ones which appear early one. Going back to them afterwards I did realise that there was value in the in this information but that it had worked out better reading the chapters in this order.

Written by Mark Needham

October 6th, 2008 at 2:20 am