Building Software Development Expertise – Using The Dreyfus Model


I’ve recently been thinking about how we build our skills when we work in teams, more, how do we as software developers become expert at what we do? Is it an organic process or do most who gain expertise in particular areas of software development actively pursue the knowledge? Is it mostly about self-study or the environment or some sort of combination of both? The point is, if we can somehow get to the root and distill the special magic of how developers become experts, we can try and build this expertise within our teams in a much more targeted way as opposed to waiting for it to happen without any direct intervention. Sounds intriguing doesn’t it, ‘building’ experts rather than waiting for them to emerge. Most places will have some kind of training program, or ad-hoc training courses that you can go on, but I have never seen any team actually directly try to build up an expert (in a particular skill) within the team, over the course of time. It would surely be a chancy undertaking, how can you tell if a person is even capable of gaining expertise and even if they did, how do you measure the extent of this expertise? I am not the first person to ask these questions :), so lets look at some of the existing body of knowledge on the subject.

The Dreyfus Model

In case you didn’t know, the Dreyfus model deals with how people attain and master skills. The Dreyfus model is applicable on a per skills basis and recognizes five 5 stages of development for a person to get to expert level.

  1. Novice – at this stage a person doesn’t really know how to be successful at what they are doing, they don’t want the big picture, but instead want unambiguous rules that will allow them to successfully accomplish their tasks. They need quick successes and will be confused when anything out of the ordinary happens.
  2. Advanced Beginner –  want to find the information they need quickly, they have some context regarding what they are doing but still not really interested in the big picture. They can use the skill at a more competent level than a novice but will still have trouble when things go wrong.
  3. Competent – have the ability to see the big picture and how it would affect the outcomes. They can deal with problems when something unexpected occurs they are able to draw on their experience when necessary. However their ability to reflect on what they do is still somewhat limited.
  4. Proficientneed the big picture and will not function well without it. They can reflect on how well they are doing and draw upon their experience to improve. Can draw relevant information from the experience of others rather than taking it in as a whole.
  5. Expert – no longer require rules and guidelines to function, will intuitively know what to do in a given situation. They will also constantly seek to find better ways of doing things.

If you want to know more about it you can always go to our second most favorite website (the first being Google :)). Basically what the Dreyfus model postulates is that novices will need strict rules and guidelines to succeed while experts will be stifled by strict rules and will not be able to apply their expertise/intuition to the fullest. In a software development context this means that a strict process would benefit a beginner and they will be more effective at what they do while more expert people will need a more organic environment to allow them to take advantage of their expertise. Andy Hunt examines the Dreyfus model in quite a bit of detail in his book, “Pragmatic Thinking And Learning: Refactor Your Wetware” and he presents it in a very favorable light regarding it’s usage in software development. While I find nothing wrong with the model itself, I do believe it misses a vital facet of the picture.

Does It Hold Up For Software Development

Applying the Dreyfus model – to software development especially – is potentially a great way to allow more expert people on the software team, the use of their fullest abilities, however it does nothing to help us build experts from the more junior people on the team! More than that, I believe that rigidly applying the Dreyfus model in the first two stages of development (novice and advanced beginner) will actually hurt the chances of a person attaining expert level knowledge in a particular skill.

Things are never that clear-cut when it comes to software. We may be lucky to have experts on our team, but on the other hand we may not. With the vast array of skills that are necessary in modern software development, most of the time the majority of people will be at most advanced beginners in a particular skill and sometimes not even that. And anyway how do you define a skill in the first place, there are no clear boundaries. Being an expert in one skill might make you competent or proficient in a dozen others and you would not be well served by being treated as a novice when it comes to those skills.

I don’t believe you can build a healthy agile team if you attempt to treat your junior people like Dreyfus novices or advanced beginners, especially when you take the typical developer mindset into account. Ever looked at a piece of code and thought that you could do better, and were itching to try? Well most developers have, it is just how we think, regardless of what our skill level is in that particular area. I believe the best thing you can do regarding the more junior people on your team would be to treat them in a similar fashion as you would your experts.  Show them the big picture, it is patronizing to think that they don’t want to know this and it would confuse them. Put a mentoring safety net in place but allow your junior people room to grow and experiment, the people who truly have potential will bloom in this environment. The rule is guidance with a light hand, NOT a clear set if hard and fast rules. Rigid processes and clear unambiguous guidelines are a crutch that no developer should allow themselves to get used to. No modern software project will have the luxury of clarity and no ambiguity, the sooner everyone gets used to it the sooner they will become more effective and productive.

So Can We BUILD Experts

It is still very fuzzy. I don’t believe the Dreyfus model helps in any significant way to build expertise within a team. It will however do us good to keep this model in mind when creating an environment where a software team can thrive. Besides relying on a developer’s personal drive to learn and get better; and providing support if needed, I don’t know of any other way to ensure that expertise develops within a software team. As usual it comes down to trying to hire great people and trying to create the right kind of atmosphere where those people can succeed. The rest you leave to nature.

I would like to come back to this topic at some point, so if anyone has any tips or ideas regarding building expertise within individuals in a software team, I would love to hear what you have to say.

Image by Marco Bellucci

  • Pingback: Building Software Development Expertise – Using The Dreyfus Model » Dreaming of an Ideal World!!!()

  • Dave

    I think the conclusion you seem to come to at the end is spot-on. Trying to build experts sounds like trying to herd cats to me…good luck! However, I think you can build an environment that fosters learning and enables the right kind of people to become experts. It does, in the end, boil down to the people, though; if the people aren’t truly passionate about what they do (in this case, software development), then I don’t think they’ll ever become experts. Sure, they can become experienced in their field, but I don’t think they’ll ever really have that intuition that helps them make the right kinds of choices in untested territory. I worked with a bunch of software developers like that at a very large company that shall remain nameless. Most of them were older, and took up software development because of the pay raise, and while they were capable of writing software that worked, I would hesitate to call any of them experts.

    Anyway, great post/blog, look forward to more posts in the future.

    • That’s right I also believe that the right environment is extremely important, but you’re also correct that in the end it is down to the people. I have also found that the right kind of people will actually help perpetuate the right kind of environment (they build on each other).

      Thanks, and i am glad you enjoyed reading it.

  • I disagree with the Dreyfus model. A few years back we recruited people from Finance / Accounting and to be honest they had a much better vision of the bigger picture as they were so conversant in the processes that supported our company’s business model. I know it may not be a fair comparison, but I think that expertise is not comprised solely from technical knowledge. Many times the users’ perspective in respects to the business domain often imposes a good barometer on what is required.

    The staff recruited have in short developed great expertise in SQL, as dealing with set theory and associations of data was right up their alley. They can work on their own, solve problems, and still branch out for new techniques when presented with technical challenges. One guy has started with C# and struggles, but as each obstacle conquered brings that person a different perspective.

    Good provocative post.

    • I really believe that no skill is an island. As you get better at some skills, you increase your chances of successfully learning other (and decrease the time it takes as well). And you’re of course right in that domain knowledge can be a tremendous help. If you need to get across technologies but have the domain knowledge, it does seem to make everything a lot easier (personal experience talking).

  • Sadly, I think there is a subset of the development community that are quite satisfied with being at the Novice or Advanced Beginner level, and don’t want to progress any further. I’ve seen some developers display harbor resentment toward other developers who try to build up the teams skills – viewing it as creating “extra” work they they don’t want to do. So, I agree, we can do things to *encourage* skills growth, but some will resist such effort.

    Put a little more cliche: you can lead a horse to water, but you can’t make it drink!

    • You’re of course right, I for one would not want to work with people like that, I’d like to hope that these kinds of people are in the minority since the very fact that you’re a software developer means you will need to update your skills constantly.

  • Pingback: » Blog Archive » Building experts using the Dreyfus Model()

  • Hi Alan,

    I don’t build experts from novices, but from competent practitioners. I also play on their strengths to do it – and I’ve certainly brought people through from experienced beginners to knowledgeable practitioners capable of balancing out inexperience on a team.

    I posted some things that I do here, together with the Dreyfus Model of Dreyfus Modelling:

    Hope you find it interesting!

    • Hi Liz,

      Thanks for that great post, I found it extremely interesting and it has given me a lot to think about. Here are some of my immediate thoughts.

      One of the consistent themes I am getting from your post is the fact that you’ve had the opportunity to work with and help grow the skills of some great individuals, they were driven and sufficiently self-starting to grow their skills in the first place. So, it all really starts and ends with the quality of the people you’re working with. You can help, guide and point but you can’t make people grow their skills. So, the types of people you work with really counts.

      I really like how you basically propose that it is not just knowledge flowing downhill, you can get your beginners to push and prod the more experienced practitioners to become more expert, I think that is great. Although once again, the quality of the people is paramount in my opinion.

      Here is another thought, coaching someone takes time and the ability to frequently re-examine and adjust your course. It would be tough if all you did was set some vague goals every 6 months and that’s all. It is almost like personal agility, you need to be able to retrospect and correct your course etc. It sounds to me like you’ve been able to do that with some people which is great. I do have to say that most teams find it really difficult to do this as it is a massive time commitment and would grow exponentially with the size of the team.

      Those are some of my immediate thoughts, but you have given me much to mull over and I’ll let it bounce around my head for a while :). And on top of all that you’ve reminded me that I’ve been meaning to write up my thoughts on the stages of competence model as well (should probably do that before I forget again). Thanks for sharing.

  • Sam

    First of all: becoming an expert or increasing your expertise requires a lot of hard work and motivation. A lot of people don’t have this motivation, and would rather stay at a secure and comfortable mediocre level. If you (not necessarily you) are motivated to do this though, read on.

    K Anders Ericsson has done a lot of great work on how people become experts. There’s a short excerpt here. It basically boils down to an awful lot of hard work that is exactly at the level of what you can do. This process can be greatly accelerated by having a good coach that can tell you what you’re doing wrong. Once you have “bootstrapped” you can continue improving yourself, but the right kind of environment and coaching is still very important. Expertise does not transfer – a vital part of your expertise is your factual knowledge, which is the reason that you can’t train general managers that will manage any kind of business.

    Geoff Colvin has written “Talent is Overrated”, and this is an easier to digest version of a lot of research, but it is by no means complete. It is however a good start if you want a more verbose description and a set of case studies of “talent hotbeds” around the world.

    Cal Newport has a blog that focuses on study techniques. Much of what he is writing is mainly targeted at material of suitable level for highschool students or undergrads, but there are some gems on his blog about research level things as well.

    • I’ve said this before in a comment I believe, but I thought “Talent is Overrated” was a great read, it confirmed much of what I was already thinking, I’ve been meaning to write a bit about it at some point. Maybe it’s obligatory for a programmer to – at some point – write about the value of hard work :).