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.

Building a Better Programmer, Part 1

Programmer productivity varies much more widely than project management spreadsheets would suggest. Differences within a moderately sized team can be 5:1, 10:1, or higher, discounting any incompetent programmers. In a previous post, I discussed how to assess the skills of the individuals. In yet another post, I extolled the more expensive talent was actually a huge bargain with their productivity boost.

But knowing the skills, are you stuck with this team? Is your only option as a project manager to swap team members out to improve your mix of skills? The answer is a resounding no. You can improve your mix of skills.

One of the attractions of the Master-Journeyman-Apprentice (MPA) model for me is that it clearly indicates the path to improving the skill mix:

• Apprentices need constant supervision as they begin to acquire skills and apply them for the first time. Gross, project-impacting mistakes await unsupervised Apprentices trying to apply their new knowledge for the first time. (Would you let a first year med student perform open heart surgery on you?) The natural supervisors? Journeymen (and not project managers!)
• Journeymen should choose the Masters from whom they will learn. It was the case with craftsmen of the Middle Ages, and is just as true today. They need exposure to such people to improve their skills to the next level. Self-taught Masters are quite rare; more often, Master programmers I know learned at the hands of another Master programmer.

Another alternative model for Master/Journeyman relationship come from academia: The relationship between PhD's and their doctorial candidates at universities. The doctorial candidate selects a professor under which to study. In exchange for guiding the doctorial candidate, the professor gains additional research capacity in his field of study. When the professor feels the student is ready, he presents him to a committee of other PhD's for examination. This committee decides whether the candidate is qualified to join their ranks. So a self-controlled Academy of Master Programmers is another interesting model.

It behooves the project manager to create an environment to supporting this learning. The rewards for supporting this learning are large productivity boosts without a corresponding growth in costs (yes, you should pay your Journeymen and Masters more, but they will be happy with less than 100% or 500% raises).

Enabling elements (in order of importance):

• Pair programming. Not only is pair programming as productive as two individuals working alone, it creates an amazing learning opportunity by pairing Apprentices with Journeymen, and Journeymen with Masters.
• Collocation. Conversations cannot occur unless people are speaking distance from each other. Throw in a convenient whiteboard, and knowledge transfer will take place.
• Project teams. Project teams that are deliberately formed to expose key individuals (Journeymen) to a Master programmer will create communication between them; knowledge will grow.
• Communities. Whether formal or informal, encourage and support communities around the skills (OOP, database, dynamic languages, .NET, etc.). Communities are quite a bit less effective than the above alternatives, primarily because they involve participants choosing to participate on their own time. This caters to a subset of candidates only.
• Training. Training is largely ineffective for all but Apprentices. But for Apprentices, it inbues them with new terminology and techniques. Hands-on training is much preferred to lectures. All training is ineffective if the techniques learned cannot be immediately applied to current project work. There is near zero retention for material that is first used a year after it is taught. Consider this when staff can sign up for education, but will have little opportunity to use the material in their normal job.

A subsequent post will talk about specific paths of transition from Apprentice to Journeyman, and from Journeyman to Master.