Journeyman to Master
Matt Heusser
Bear with me here - I'm the one that introduced the Lewis article, and I am a huge fan of. At the same time, I believe it is possible to mis-interpret the words a bit, and want to be careful.
Take, for example, the 11th century master mason working on a cathedral. Does he think he is doing "the best stone cutting i the county" or does he believe he is "building a cathedral?"
I believe the second attitude is generally more mature. Decisions like when to take on technical debt need to be balanced by the needs of the business.
One of things that I hear (and I like) from this group is about the broadening of the focus to master, to include more mentoring, leading, possibly project management, better handling of clients, etc. The "whole picture."
Thus, the apprentice (for the most part) does what he's told. The journeyman asks "What is the right technical approach?"; the master asks "what does the business need, and how can I accomplish that with integrity?"
That's just me talking, it's certainly wrong in several ways and I'm open to refinement. :-)
regards,
--heusser
Ben Rady
Enrique Comba Riepenhausen
> Bear with me here - I'm the one that introduced the Lewis article,
> and I am a huge fan of. At the same time, I believe it is possible
> to mis-interpret the words a bit, and want to be careful.
>
> Take, for example, the 11th century master mason working on a
> cathedral. Does he think he is doing "the best stone cutting i the
> county" or does he believe he is "building a cathedral?"
>
> I believe the second attitude is generally more mature. Decisions
> like when to take on technical debt need to be balanced by the needs
> of the business.
I absolutely believe that the later is, as you mention more mature,
although with some connotations to it. Many people, specially in the
software development industry bend to the 'pointy haired bosses' and
do whatever the business asks them to do. We could argue here if this
is the right way to really 'build a cathedral' or just postponing a
tick it's downfall.
A craftsman always tries to strive for excellence while doing his
work, therefore providing the most value to his customer. Due to the
expertise, acquired in long years of practice, the craftsman is able
to create, using the best of his professional judgement, the best
solution for a customer. When building software, for instance, we
might sometimes envision a 'perfect' architecture. Due to time or cost
constraints though, we might choose a simpler solution to the problem
(always advisable) so that the customer can enjoy his product earlier.
In this days time to market seems to be really crucial!
> Thus, the apprentice (for the most part) does what he's told. The
> journeyman asks "What is the right technical approach?"; the master
> asks "what does the business need, and how can I accomplish that
> with integrity?"
I agree with this simplification of the Apprentice/Journeyman/Master
explanation. I would say that the Journeyman also asks himself the
question "what does the business need, and how can I accomplish that
with integrity?"; the real difference lies in the master himself. By
definition, or as far as I believe, a master has attained a level of
proficiency that is very hard to reach. He not only understands the
art of software development, but also explores new ideas and
techniques of his own invention; he tries to make the art go to the
next level by applying new points of view, and seeking to offer that
as a masterpiece or new technique.
One example here. Unit testing is a really old technique, many
developers have been testing their software by running small
simulations that would stress their applications or units in a certain
way. Until Kent Beck wrote the xUnit family of frameworks (specially
JUnit) and defined TDD this techniques where hard to master and
required a lot of setup. Due to his insight he actually gave us a way
of testing our applications better, faster and in a very efficient
way. He didn't only give us a tool, but also a practice that would
support that simple yet powerful tool and practice!
Enrique
Kerry Jones
When talking about Software Craftsmanship or any kind of learning I
find the three levels of Apprentice, Journeyman, Master a bit
limiting. When trying to categorize myself or others I find there are
more subtle differences that would identify different levels within
the Journeymen category. I find that in everything I learn I would
classify myself at different levels depending on the skill and how
long I've practised it. There are many skills required in becoming a
Software Craftsman and it's quite likely that someone would be a
Journeyman in some of the required skills and not in others. When is
someone qualified enough to be called a Journeyman? Is there a set of
skills that can/have been identified?
Have any of you read much about the Dreyfus Model of Skills
Acquisition? This article by Dan North is quite good and the model
seems to my mind to be a better model and description of levels of
learning.
http://www.infoq.com/articles/better-best-practices
I also wrote up my notes after seeing Dave Thomas do a talk at QCon in
2007 about the model.
http://blog.livingroomarchitect.com/2008/05/learning-agile-dreyfus-way-part-1.html
Mark Needham
I find it quite interesting looking at your current team and seeing what level you think people are at for different skills. The way they talk about stuff is quite different I find.
What I'm still keen to try and work out is how you can practice so that you can move between the levels more quickly and the more meta skill of learning to learn. Dave Thomas has a talk on it (might be the talk you saw? http://www.infoq.com/presentations/Developing-Expertise-Dave-Thomas) where he is basically saying how he has basically acquired the skill for progressing quickly through the Dreyfus Model for any new skills he wants to learn. Pretty cool stuff though.