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.