Masters, Journeymen, and Apprentices: Part 3

In the previous blogs on this topic, I claimed that there is a huge productivity difference among Masters, Journeymen, and Apprentices when working on significant, business critical systems:

Role	Productivity
Apprentice	1x
Journeyman	2x
Master	5-10x

This is observed productivity from many Agile projects.

So, what do you do with this information?

1. Assess the skills of your developers
2. Adjust project staffing, absorbing all the Masters and Journeymen you can find (the rate difference does not equate to the productivity difference)
3. Work to boost the skills of your developers

Let's start with the first point: Assessing the skills of your developers. For this example, these guidelines here apply to OO skills in particular, but you can easily morph these into other skills.

• Apprentices are those programmers that are not yet Journeymen. You do expect Apprentices to be competent in a programming language and associated tools (IDE, unit test tools, debuggers). They can write code without fumbling and resorting to syntax guides. They can use the right tool at the right time. They may be learning what bad OO code looks like, but lack the tools to figure out how to get rid of it.
• Journeymen have developed a broad OO vocabulary. They understand OO principles, and apply these principles in their code. They have a rich set of design patterns they exploit, and a broader set they understand. They can quote solutions to code smells drawing from their refactoring vocabulary. They are clever users of their tools, exploiting the nuances missed by Apprentices. Journeymen stuggle, however, when trying to design an object solution to a business problem. They are not yet comfortable with exploiting their OO design skills to address these problems.
• Masters are Journeymen with the extra ability to decompose a business problem into its parts. They also discern refactoring paths for ugly code, particularly where a series of patterns must be applied. The source of their productivity lies in their ability to find a great solution (simple and elegant) quickly, whereas Journeymen may have a few false starts.

So how do you assess where each of your developers fit? The easiest way is to have a Master programmer work with each programmer for a while (as little as 30 minutes). That will be enough for a Master to discern the current level of a programmer. You might also get a feel for the potential of a programmer in that short time, but that is a bit more dangerous.

You don't have a spare Master programmer around to do the assessment? For Apprentices and Journeymen, there is a good alternative. Since the difference is largely knowledge based, testing is a valid approach. Test their vocabulary; show them bad code, and ask how they would fix it. Personally, if a programmer can describe the Composite design pattern to me with three or four places where it would be appropriate, I am pretty sure he is at least a Journeyman.

How about Masters themselves? That is a bit tougher, but I would propose the following: Master programmers know Master programmers when they meet them. They talk a different language; they discuss problems in higher, abstract terms. They can relate experiences using almost any design or refactoring pattern. Verify that the legendary programmer in your organization is a Master programmer by getting references from luminaries in the field. Once you have found one, let her figure out who the others are. Chances are she knows a couple, and those couple know the rest.

Warning: Don't be surprised if you have no Master programmers. Don't be surprised if some of your architects think they are, but are really not.

More in the next post about growing Journeymen and Masters.