Masters, Journeymen, and Apprentices: Part 2

I previously suggested that classifying programmers as Masters, Journeymen, and Apprentices provided a better way to understand and manage the productivity differences among programmers. The analogy to craftsmen of the Middle Ages is deliberate:

• It reinforces the image that programming is a learned craft, not some special science. I am definitely in the camp of thinking with The Pragmatic Programmers.
• Skills like OOP proficiency seem to be learned best from others; books faire poorly in teaching these skills. This aligns with the craft model well.
• It defines some tiers of productivity, but not too many to make planning difficult.
• The level of independence (or rather, the need for supervision) is modelled well. Apprentices need constant watching; journeymen do not.
• Journeymen in the Middle Ages would find masters under which to study. There was an implicit agreement to learn and teach that was largely voluntary on both parties. I like the self-selected learning concept.
• It is a skill classification, not a job title. This aligns better with Agile and Agile teams.

My colleagues have suggested a few nice refinements or alternative systems.

One idea I like is breaking the Apprentices into two classifications: Those who are learning the skill, and those who are not (because of ignorance or just not choosing to invest in that particular skill). This segregation aligns with the different treatment of the two groups. Learners are encouraged, nurtured, and provided with opportunities to learn. The non-participants are educated in the advantages of the skill to solicit their participation.

Another colleague, Dan North of ThoughtWorks, uses a three-tier system based on his school of Japanese martial arts: Shu, ha, re, with re corresponding to apprentices. In his school, the lowest tier, re, focus on the mechanics of the moves: blocks, counterpunches, avoidance. Once the body learns the moves, the mind moves toward applying them in situations. This is the domain of the ha level of competence. Practioners achieving the shu level are innovating; in an unexpected situation, these practioners may conceive of new techniques on the fly because of their fundamental understanding of the principles.

The appealing aspect of Dan's model is that ha are expected to teach re, and shu are expected to teach ha. Indeed, you cannot achieve the shu level unless you show you are also competent to convey the knowledge to others. Dan's model reflects my belief that some programming skills (like OOP proficiency) are most easily conveyed in person, not by books.