Building a Better Programmer, Part 2

To increase the productivity gains promised by the Master-Journeyman-Apprentice (MJA) model, programmers must progress up in the model. In Part 1 of Building a Better Programmer, we detailed the techniques by which programmers can gain the skills resulting in improved productivity. In this post, I will discuss paths to programmers enrichment, likely timeframes for the process, and failure rates. I will again draw from the MJA model for learning OO skills, a key enabler for Agile application developement.

Apprentice to Journeyman

If you can move your Apprentices to Journeymen, you can effectively double your productivity for those complex, business critical systems you maintain and enhance. There are certain enablers that are required for this transition:

• Willing Apprentices (supported in their efforts by management)
• Journeymen or Masters from which to learn

I have used a couple of paths to assist the transition of programmers from Apprentices to Journeymen, both in ThoughtWorks and in the industry with good results in both cases. For OO programming, the goal is the same in both cases: Teach the Apprentice to think like an object programmer. That means teaching the Apprentices to break problems down in a different way, to recognize when programmers are structured poorly per OO principles, and build up a repertoire of techniques by which to do this.

Path 1 involves a combination of training and mentoring. Training assists in quickly providing the new vocabulary for the Apprentice, and mentoring provides the continued support for applying the new techniques to the daily problems the programmer addresses. Without mentoring, the value of the training is significantly diminished. Without mentoring, the pressures of delivery will drive the Apprentice to apply the old, familiar techniques to solve the problem. Old habits are reinforced; new techniques are forgotten. And worse, the new techniques become labeled "theoretical" or "academic" or "irrelevant to real problems." Net result: education wasted.

Path 2 forgoes the training, and simply provides the mentoring. The training is gained by working closely with Journeymen and Masters. Pair programming is important in this environment; collocation is absolutely essential. Path 2 takes longer; the Apprentice must pick up the vocabulary in the course of the work. Path 2 is probably more expensive; the productivity gains come later, and the time of Journeymen and Masters is taxed in doing bits of training here and there as the need arises.

There is a Path 3: Pick it up from reading the books. Self-taught Journeymen are rare, but I have met them. They also took a frighteningly long time to make the transition, with a lot of discarded bad code in the wake. I cannot recommend this approach for even the brightest of programmers.

If you can adopt Path 1 (training and mentoring), you should expect most of your programmers (60% or more) to make the transition from Apprentice to Journeyman in about six months. Some will be there quicker; some will take a bit more time. Expect failures; in my experience, about 20% cannot make the transition at all. The individuals who will not make the transition can be identified pretty quickly (a month or less); they can be placed back in the roles they had before and continue to be productive for the organization. The usual cause of the failure to transition is that they lack the conceptual skills to be effective OO programmers. I have seen a few other cases of failures in senior people. In these cases, the senior person realizes that the junior people understand this better than they do, and choose to disengage rather than reveal the lack of a gap. I take these failures personally; I feel I didn't create an environment where they could learn safely.

I developed specific training for this transition over a decade ago. The first class affectionally called it OO Bootcamp. I brought the course with me to ThoughtWorks several years ago, and it still carries that moniker today. I will post more on OO Bootcamp in the near future.

Journeyman to Master

The transition from Journeyman to Master is much more difficult. You should not expect more than 20% of your staff to ever make the transition. Most of your good candidates have deviated from strict application development, and are probably serving as your system and application architects, effectively ceasing their learning as programmers.

But with the whopping productivity boost and the ability to leverage Masters to make more Masters, it is well worth investing in their growth.

Masters must be excellent programmers. Their vocabulary is deep and wide. By and large, they have extensive experience applying their knowledge to real world problems. Similarly, their conceptual skills are excellent. This allows them to manipulate objects in their heads, forming solutions to difficult problems. Finally, domain knowledge is helpful, but not quite essential.

If you describe a business problem to a Master programmer, she will see objects dancing in her head, forming patterns that solve the problem. This comes from developing an inherent sense of object relationships, a suite of problem-to-object-solution maps, and confidence born of solving similar problems before.

Hence, the transition from Journeyman to Master can take a while. In general, expect a couple of years. I have seen a few instances of faster transitions (only six months or so); in all cases, the individuals were extremely bright, conceptual thinkers, and had many years of programming experience under their belts. (They were also colleagues from ThoughtWorks India!)

Managing Programmer Improvement

In the prior post, I listed the techniques to enable programmer skill growth. In order of importance, they are pair programming, collocation, communities, and training. Project managers and senior managers should facilitate these practices as much of this as possible.

There is one other charter I would give a project manager when a focus on skills is important: Bring back better programmers. In other words, measure the project manager on both delivery and skills growth. If the project manager delivers the project but doesn't grow the people, then, well, at the least a permanent productivity boost to the organization has been lost; at worse, gross negligence has occurred, and I don't want to use that project manager again.