Putting the Journey into Journeyman
Really, the title of this post should be, “Putting the journey into journeyman, taking it out, and putting it back in again,” but that’s impractically verbose.
It’s only a model
At LeadingAgile we like to use the model of software development expertise that Meilir Page-Jones published way back in the last millennium. We find the model useful for understanding and tracking our own progress as software development professionals. The model proposes that we pass through up to seven stages in developing our expertise over the course of our careers:
- Innocent
- Exposed
- Apprentice
- Practitioner
- Journeyman
- Master
- Researcher
Innocent means what it appears to mean: You’ve never heard of X. You can go from Innocent to Exposed by reading an article or watching a video about X. It can take as little as a few minutes.
You can go from Exposed to Apprentice by reading more about X, maybe working through a few tutorials or dabbling in X on your own, and then making a definitive decision to work with more advanced practitioners of X to learn from them. It can take hours or days, or it can stretch out to a couple of years.
You go from Apprentice to Practitioner by diligently practicing the things your mentors and colleagues show you in the context of real work. You might say Apprentice loosely corresponds to a third-year undergraduate student or an entry-level job in software development work; say, as a programmer, tester, system administrator, database administrator, or some other hands-on role. Doesn’t really matter which role, particularly. The time frames get longer and fuzzier as we progress through the model.
Typically this transition can take from about two to eight years. The cultural boundary between “finishing school” and “starting work” isn’t important. Those years can include the last couple of years of undergraduate projects fused with the first few years of work in the field, or equivalent learning and experience outside the formal educational system or working on Open Source projects. The important thing is what you do and how seriously you take it.
The majority of people who earn a living in the software field stay at the Practitioner level for the remainder of their careers. There’s nothing wrong with that. Practitioners are good at their work. It’s just that there are other aspects of their lives that are more meaningful to them. Perfectly normal and healthy. There’s no “rule” that says you have to push yourself all the way through the seven stages. As Patsy observes upon seeing Camelot in Monty Python and the Holy Grail, “It’s only a model.”
And then there are people who are internally driven to hone their skills to a higher degree. They will grow from Practitioner to Journeyman in their own time, as a natural consequence of their curiosity and deep interest in the work. After some time (decades, maybe), the Journeyman becomes recognized as a Master by others in the field (beware of those who call themselves “master”). Think of someone like, for instance, “Uncle Bob” Martin.
On the road from Master to Researcher, most people start to lose interest in building application software and turn their attention more to “meta” issues in software engineering. Some of them achieve the Researcher level, at which point they’re all but useless for any “real” work, but they contribute to the advancement of the field by noticing connections and patterns that aren’t visible from the perspective of Practitioners and Journeyman, and of which Masters might just be becoming aware. Think of someone like, for instance, Martin Fowler.
So what?
Okay, so there’s a model. Are we going to tie this back to the title, or what?
Yeah, yeah, sure.
There’s this word, “journeyman.” It seems to be understood in two different ways. English-speakers tend to understand journey in the sense of a trip or a voyage.
Another company we know and like has an internal model that includes the word journeyman. They take the meaning as “one who is on a learning voyage” (paraphrased). For them, then, a journeyman is a relatively inexperienced developer. It’s a person who wants to become an artisan (in that company’s parlance).
About ten years ago, Corey Haines hit the road for a year or so, visiting software development organizations and sitting in with their teams. It was his “journey” to learn and hone his craft. He still calls his blog On being a journeyman software developer. After all, he’s still on a lifelong voyage of learning and discovery. He talks about it in a 2011 interview with Matt Heusser, entitled Putting the “Journey” in Journeyman Software Developer. In that situation, “journey” is understood to mean “voyage” or “quest.”
So, the question is: If a journeyman is a relatively inexperienced practitioner, then why does the Page-Jones model place the Journeyman stage higher than the Practitioner stage, or even the Apprentice stage?
The answer is: The “journey” in “journeyman” has nothing to do with traveling, beyond traveling from home to work and back.
This whole “journeyman” thing in the software field is part of the broader notion of software craftsmanship. It harks back to ancient times when craftspeople joined guilds and learned their trades as apprentices under the tutelage of a master, until such time as they were ready to ply their trade independently for pay.
A day’s pay.
“Journey” means “day.”
A “journeyman” is a “day man.”
When you were an apprentice, it was the master who got paid. Now you’re independent. Now you get paid.
By the day.
Get it?
Here’s the etymology in a nutshell:
Implications
When we’re recuiting for technical coaches and player/coaches, and we say we’re looking for people at the Journeyman level, we aren’t looking for apprentices.
We do travel a lot in our work, so there’s that for what it’s worth….