Over the past six years I have supervised external developers that have various stages of knowledge, abilities and skills. This has led me to consider that the standard model of skill acquisition does not apply in the context of software development.
The accepted method of describing skill acquisition is the Dreyfus model. In this an individual goes through five stages:
In my experience, most of these external developers have been either competent or proficient, however many of them consistently made fundamental mistakes. This has led me to re-evaluate how I should manage these situations.
I am not intending to refer to the 'zero to programmer' journey because it is outside my area of expertise - this is about programmers who are already competent or proficient. This is to describe a model of attainment which will help them acquire the skills needed to contribute effectively to a project.
In considering the model below, whether mentoring, coaching or self-learning the objective is always to get to the final stage by fully understanding the values and principles then performing the practices of the skill. In reality, progress through these stages is more often step by step.
They don't know that there are rules
In this stage there is neither internal discipline nor external discipline. If I have learnt anything from this experience it is this: if a team or individual is in this mode, you must not let a single line of code have written to make it into production. They has to be movement to the next stage.
They know that there are rules, but they don't know what they are
In this stage there is some internal discipline and a great deal of external discipline. This mode is substantially unproductive; it takes more effort to manage them and this outweighs the value of the code they produce. This is unsustainable; however with dedicated mentoring, pairing and code review, it is a necessary step in the process to the next stage.
They know what the rules are, but they don't know why they are there
In this stage there is a balance of internal discipline and external discipline. This mode is the classic '1x' productivity. Having attained this stage is a measure of progress, but inefficient in the long term. The level of supervision required drains the efforts of the more experienced members of the team. So further mentoring, coaching and pairing is needed.
They know what the rules are and why they are there
In this stage there is a significant amount of internal discipline and only a limited external discipline is needed. This is much more productive; good QA systems of pairing / reviewing can lead to the efficient creation of high quality code. However, just as in the previous two stages, this work is based on discipline and rules. If the discipline is removed, the teams and individuals will, in time, revert back to their previous methods and practices.
Why would you do it any other way?
In this final stage there is no need for discipline, either internal or external. The rules are 'obvious'. It is the right thing to do.
The previous stages have followed a natural course, in my experience, most people are open to progression and improvement. However changing Mind-Set is a different attainment of understanding and is not guaranteed, even with the best intentions of all involved.
My experience is that the change to the Mind-Set stage cannot be artificially imposed - even upon oneself, even when you really want to get to that stage. It just happens.
1. Recognise the stage that your team members have attained, and act accordingly
Whether they need supervision or mentoring and coaching or just occasional review, time has to be allowed to provide for their continued progress.
2. Recognise the stage that you have attained, and act accordingly
This is much more difficult, it is easy to deceive oneself. I have found the following to be helpful:
If I am running around like a headless chicken, I am probably in the Chaotic stage.
If I have to keep researching 'stuff' via Google, Books, SO etc. I need Supervision. You have to supervise yourself, monitoring and evaluating your own work; being prepared to do this is the key.
If a new situation causes me to re-think my approach to a problem, then perhaps I'm just being Productive; applying the rules but not really knowing why. This is the time to study and talk with others.
If I am working well, but I recognise that there are things I do reluctantly. I know I should do the practices, because it will come back to bite me if I do not. However if I resent the process or time taken, then I am just being Autonomous using self-discipline, I have not fully attained the Mind-Set.
'Well... Duh.' - probably an indication of the Mind-Set stage. But be careful, it can be confused with Chaos.
3. Some skills do not follow the happy path
In my experience the acquisition of many skills in software development progress reasonably smoothly through the stages I have identified above.
Process: Establishing the rules >> applying the rules >> understanding the rules >> recognising the values and thought processes underlying the rules >> transcending the rules. This seems to work. However there are exceptions; when such an exception occurs then the process above does not function well and there is potential for fundamental misunderstanding.
Exceptions: I do not think that these exceptions are intrinsically more difficult skills than others. Instead I think they differ in one important aspect: They require the change to the Mind-Set stage as a pre-requisite before any real progress is possible.
I would list some examples of this category as: OO, XP, REST, Agile, TDD, there are more...
These exceptions are a different class of problem - and one that requires us to understand that for these particular skills, the change to the Mind-Set stage is the only real indicator of progress.
As we cannot guarantee a path to attain the Mind-Set stage, all we can do is point the way, create a respectful environment in which it can take place and lead by example.