How do you tell a master craftsman?
Ron Ziroby Romero
master craftsman (of any profession). Then we went on to discuss how
you can tell that someone is a master craftsman. I find his answer
illuminating:
1. They should be able to talk their craft and, if you're not a master
yourself, they will lose you and go over your head and talk about
things you don't understand. This was from a child's view, but I
interpret it as "They must be able to talk up their craft".
2. They should be able to create a sample on demand. He was thinking
about small crafts when he mentioned it, but when we talked about
bigger things (like skyscrapers), we decided a small test problem
would suffice. .
3. (and this I think is the most important one) They should show you
their previous work. They should be able to say, "Look, I created
these high quality things in the past, so I can create high quality
things for you in the future."
The book Software Craftsmanship book mentions that to be a master, you
must have a masterpiece. To claim that you're a master, you must be
able to show some really good work. So in our discussion of how do
you tell a master craftsman, the answer is simple: look at their
work.
When you hire an artist (painter, photographer, sculptor, etc.), you
look at their portfolio. All artists have one, and it's how they get
work. So, if we're craftsman, we should have portfolios. Résumés are
similar to portfolios, but a) they don't emphasize actual completed
works enough, and b) they're dry and boring. So maybe we need to
start making multimedia portfolios to highlight our abilities as a
craftsman. I picture web sites with screen shots, customer
testimonials, sample code, links to your blog and other sites, and
links to free software or other non-work projects you've created.
The key here is, if you want to convince someone that you're a master
craftsman, show them your work and your masterpieces.
Ron "Ziroby" Romero
www.ziroby.com (which has some portfolio elements, but needs to talk
about my actual for-pay work)
[Cross-posted to my blog at http://ziroby.wordpress.com/2011/01/17/how-do-you-tell-a-master-craftsman
]
Ralf Westphal
And it´s so cool you discussed that with your child son!
Your conclusion: "Show me your work - and I´m gonna tell you, if you
´re a master craftsman."
Or more generally put: You can tell a master craftsperson from his/her
work.
I agree 100%.
But this raises the question:
What makes a work a masterpiece?
How do you tell, if some software not only has been crafted by a
master, but truely is a masterpiece?
What´s are the criteria of the SC movement for that?
>
> ]
George Dinwiddie
> But this raises the question:
>
> What makes a work a masterpiece?
>
> How do you tell, if some software not only has been crafted by a
> master, but truely is a masterpiece?
> What´s are the criteria of the SC movement for that?
Why should the "SC movement" have a criteria? Sure, the medieval guilds
had criteria, but that was as much to limit competition as anything.
Sure, the art salons of Paris had criteria, but that ultimately served
to create alternative venues for those who preferred different criteria.
Wouldn't it be better for everyone to have individual criteria than to
have a centralized criteria?
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
Ralf Westphal
> Why should the "SC movement" have a criteria? Sure, the medieval guilds
> had criteria, but that was as much to limit competition as anything.
> Sure, the art salons of Paris had criteria, but that ultimately served
> to create alternative venues for those who preferred different criteria.
yardstick?
>
> Wouldn't it be better for everyone to have individual criteria than to
> have a centralized criteria?
well, there will be as many yardsticks as there are people looking at
software.
That cannot possibly be what anybody wants from SC.
People are looking for guidance: customers and developers alike. And
you want to throw them back on themselves?
What else is a quality movement good for if it does not give any
guidance on what quality means. (Or isn´t SC about quality?)
Am I missing anything?
Adewale Oshineye
Patterns: http://apprenticeship-patterns.labs.oreilly.com/ch07.html is
about this topic.
Essentially it's possible to tell that someone is a better software
than you are. However that's not the same as detecting mastery.
If I'm not a software developer it becomes even harder to detect
mastery. It gets even harder when you remember that many software
developers become famous for things that are, at best, correlated with
their skill in software development. This means we can't even just
assume that famous software developers are masters.
I tend to find questions about detecting mastery become sterile or
self-congratulatory. For example:
http://tapestryjava.blogspot.com/2004/07/this-great-hacker-does-use-java.html
made me cringe the first time I saw it.
I think that we'd benefit more from focussing on how to improve our
skills rather than on how to become masters. That way we're thinking
about small concrete things we can do to improve rather than worrying
about defining some abstract concept.
Curtis Cooley
> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
--
Curtis Cooley
curtis...@gmail.com
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
George Dinwiddie
On 1/18/11 2:51 PM, Ralf Westphal wrote:
> On 18 Jan., 16:46, George Dinwiddie<li...@iDIAcomputing.com> wrote:
>> Why should the "SC movement" have a criteria? Sure, the medieval guilds
>> had criteria, but that was as much to limit competition as anything.
>> Sure, the art salons of Paris had criteria, but that ultimately served
>> to create alternative venues for those who preferred different criteria.
>
> You´re seriously asking, why the SC movement should provide any
> yardstick?
Yes, I am.
>> Wouldn't it be better for everyone to have individual criteria than to
>> have a centralized criteria?
>
> If everyone can make his/her own yardstick for master quality, then,
> well, there will be as many yardsticks as there are people looking at
> software.
We have that in any case. People do not discard their own yardsticks
because someone else is touting theirs.
> That cannot possibly be what anybody wants from SC.
> People are looking for guidance: customers and developers alike. And
> you want to throw them back on themselves?
I don't think that's what I said. But I don't think that telling people
what's right and what's wrong is the answer, either. I'd rather develop
their ability to make their own judgment.
> What else is a quality movement good for if it does not give any
> guidance on what quality means. (Or isn´t SC about quality?)
> Am I missing anything?
I don't this Software Craftsmanship is about being the arbiter what what
is quality and what is not. I think it's about encouraging quality.
It's about discussing what quality is and is not. It's about taking
bold stands for ourselves, not making decisions for others.
Or so it seems to me.
Ralf Westphal
individual capability to tell a masterpiece from crap?
Is that right?
But then: How can I build up such a capability? Wouldn´t I need to be
shown acknowledged masterpieces as well as crap to hone my skill?
Isn´t that what happens in all other industries? Isn´t that what
happens in a master-apprentice relationship: the master shows the
apprentice what he thinks is a masterpiece and tell him, "Look, this
is a masterpiece. Study it thouroughly! Try to immitate it."
For that to happen, though, the master already needs to have a notion
of what makes something a masterpiece.
So if there are any masters around in the SC movement, they at least
should have an idea of what the properties of masterpieces are.
Otherwise they would not be masters, wouldn´t they.
Or if there are no mastery (yet) to be found in the SC movement, then
we´re all still apprentices. Shouldn´t we then strive for a common
understanding of what a masterpiece makes?
George Dinwiddie
On 1/19/11 3:46 AM, Ralf Westphal wrote:
> George, you want the SC movement to be a place for growing the
> individual capability to tell a masterpiece from crap?
> Is that right?
>
> But then: How can I build up such a capability? Wouldn´t I need to be
> shown acknowledged masterpieces as well as crap to hone my skill?
> Isn´t that what happens in all other industries? Isn´t that what
> happens in a master-apprentice relationship: the master shows the
> apprentice what he thinks is a masterpiece and tell him, "Look, this
> is a masterpiece. Study it thouroughly! Try to immitate it."
If you do that, you'll get a crappy imitation, not a masterpiece.
Imitation is a decent learning tool for an apprentice, yes. Imitation
will not take you down the road to mastering a skill.
> For that to happen, though, the master already needs to have a notion
> of what makes something a masterpiece.
Do you think a master gets that notion from being told "this is what a
masterpiece looks like?"
No, a master gets that notion by asking questions and looking at all.
> So if there are any masters around in the SC movement, they at least
> should have an idea of what the properties of masterpieces are.
> Otherwise they would not be masters, wouldn´t they.
>
> Or if there are no mastery (yet) to be found in the SC movement, then
> we´re all still apprentices. Shouldn´t we then strive for a common
> understanding of what a masterpiece makes?
Who anoints someone as a master?
I say no one. Being a master is what we may strive to achieve. It's
not a destination. It's not an award bestowed on us.
Jerry Andrews
If you do that, you'll get a crappy imitation, not a masterpiece. Imitation is a decent learning tool for an apprentice, yes. Imitation will not take you down the road to mastering a skill.
Who anoints someone as a master?
I say no one. Being a master is what we may strive to achieve. It's not a destination. It's not an award bestowed on us.
George Dinwiddie
On 1/19/11 1:42 PM, Jerry Andrews wrote:
>
>
> On Wed, Jan 19, 2011 at 11:45 AM, George Dinwiddie
> <li...@idiacomputing.com <mailto:li...@idiacomputing.com>> wrote:
>
> If you do that, you'll get a crappy imitation, not a masterpiece.
> Imitation is a decent learning tool for an apprentice, yes.
> Imitation will not take you down the road to mastering a skill.
>
>
> In software, I'm going to disagree with you on this one. I often learn
> by imitation--and then by understanding, followed by refinement.
Then you're not disagreeing with me. You became better by looking for
understanding and refining what you learned via imitation. Not by
imitating something touted as a masterpiece.
Chris Readle
Jon Jagger
> wrote:
>>
>> Imitation is a decent learning tool for an apprentice, yes. Imitation will
>> not take you down the road to mastering a skill.
Aren't those two sentences a bit contradictory?
Suppose you're an apprentice on the road to mastery?
> In software, I'm going to disagree with you on this one. I often learn by
> imitation--and then by understanding, followed by refinement.
I agree with the disagree. I think it's easy to under-estimate how
important it is to see good examples you can try to imitate. Babies
see their parents walking. Conversely, sometimes you hear stories of
feral children who don't learn to walk. And it's apparently perfectly
normal for walking to be delayed in blind babies.
It reminds me of the old chestnut of whether it is better to think
your way into acting differently, or to act your way into thinking
differently. I certainly feel my natural tendency is to do too much of
the former and not enough of the later.
Cheers
Jon
George Dinwiddie
On 1/19/11 2:08 PM, Jon Jagger wrote:
>> On Wed, Jan 19, 2011 at 11:45 AM, George Dinwiddie<li...@idiacomputing.com>
>> wrote:
>>>
>>> Imitation is a decent learning tool for an apprentice, yes. Imitation will
>>> not take you down the road to mastering a skill.
>
> Aren't those two sentences a bit contradictory?
> Suppose you're an apprentice on the road to mastery?
How far do you think that imitation will take you toward mastery?
Chris Readle
Jon,How far do you think that imitation will take you toward mastery?
On 1/19/11 2:08 PM, Jon Jagger wrote:
On Wed, Jan 19, 2011 at 11:45 AM, George Dinwiddie<li...@idiacomputing.com>
wrote:
Imitation is a decent learning tool for an apprentice, yes. Imitation will
not take you down the road to mastering a skill.
Aren't those two sentences a bit contradictory?
Suppose you're an apprentice on the road to mastery?
Jon Jagger
>>>> will
>>>> not take you down the road to mastering a skill.
>>
>> Aren't those two sentences a bit contradictory?
>> Suppose you're an apprentice on the road to mastery?
>
> How far do you think that imitation will take you toward mastery?
Perhaps not very far. Not on it's own. But not no distance from the
start either. I just wanted to temper your second sentence a little
that's all. If I was a novice reading the second sentence I feel I
might have misunderstood it.
Cheers
Jon
Eric Ridgeway
George Dinwiddie
On 1/19/11 5:28 PM, Eric Ridgeway wrote:
> I do want to add a little to this part of the discussion....
>
> I am not only a software apprentice but I am also a bonsai apprentice. I
> study with my long time friend and 52yr veteran of the art (he is 71 so
> that is 50yrs of doing something, every day) who is also internationally
> recognized as being a master in the art. In my apprenticeship I spend a
> lot of time watching..... asking questions....practicing ... failing...
> practicing... asking questions... discussing theory and concepts....
> rinse repeat..... with each iteration I come closer to mastery at some
> level. It will be many years before I can even be considered a master of
> the art... If ever (I hope to achieve mastery some day).
>
> The point of that being that imitation is an important part of mastering
> a craft. Imitation how ever is only useful when one understands the core
> behind what they are imitating.... this is something that is often learn
> WHILE imitating. In other words it is often only possible to learn what
> to do by doing it... and through doing on can gain understanding......
>
> does that make sense?
Yes, thanks. There is much involved, and imitation is just the beginning.
Adewale Oshineye
> Eric,
>
> On 1/19/11 5:28 PM, Eric Ridgeway wrote:
>>
>> I do want to add a little to this part of the discussion....
>>
>> I am not only a software apprentice but I am also a bonsai apprentice. I
>> study with my long time friend and 52yr veteran of the art (he is 71 so
>> that is 50yrs of doing something, every day) who is also internationally
>> recognized as being a master in the art. In my apprenticeship I spend a
>> lot of time watching..... asking questions....practicing ... failing...
>> practicing... asking questions... discussing theory and concepts....
>> rinse repeat..... with each iteration I come closer to mastery at some
>> level. It will be many years before I can even be considered a master of
>> the art... If ever (I hope to achieve mastery some day).
>>
>> The point of that being that imitation is an important part of mastering
>> a craft. Imitation how ever is only useful when one understands the core
>> behind what they are imitating.... this is something that is often learn
>> WHILE imitating. In other words it is often only possible to learn what
>> to do by doing it... and through doing on can gain understanding......
>>
>> does that make sense?
>
> Yes, thanks. There is much involved, and imitation is just the beginning.
>
> - George
practice. Ericsson's writing on the topic is linked to in the Further
Reading section but this: http://jsomers.net/blog/deliberate-practice
is a more accessible explanation of the same topic.
Adam Sroka
spectrum of behaviors that are useful in improving your craft.
Certainly there is value in modeling the behavior of practitioners
more skilled than yourself.
I think the key to mastery is introspection. We need to know why we
are doing what we are doing, and then we need to reflect on it and try
to improve it further. However, it is possible to improve by imitation
before achieving understanding. In fact, the Shuhari model is based on
the assumption that first we imitate, then we understand, then we
transcend.
George Dinwiddie
On 1/19/11 7:08 PM, Adam Sroka wrote:
> Perhaps a better way to say it is that imitation is only one of a
> spectrum of behaviors that are useful in improving your craft.
> Certainly there is value in modeling the behavior of practitioners
> more skilled than yourself.
>
> I think the key to mastery is introspection. We need to know why we
> are doing what we are doing, and then we need to reflect on it and try
> to improve it further. However, it is possible to improve by imitation
> before achieving understanding. In fact, the Shuhari model is based on
> the assumption that first we imitate, then we understand, then we
> transcend.
Yes, I never said that imitation had no part and no value. Only that it
wouldn't take you to mastery.
Adam Sroka
<li...@idiacomputing.com> wrote:
> Adam,
>
> On 1/19/11 7:08 PM, Adam Sroka wrote:
>>
>> Perhaps a better way to say it is that imitation is only one of a
>> spectrum of behaviors that are useful in improving your craft.
>> Certainly there is value in modeling the behavior of practitioners
>> more skilled than yourself.
>>
>> I think the key to mastery is introspection. We need to know why we
>> are doing what we are doing, and then we need to reflect on it and try
>> to improve it further. However, it is possible to improve by imitation
>> before achieving understanding. In fact, the Shuhari model is based on
>> the assumption that first we imitate, then we understand, then we
>> transcend.
>
> Yes, I never said that imitation had no part and no value. Only that it
> wouldn't take you to mastery.
>
Yes, but some people seemed to interpret what you said that way. I was
just hoping to help clarify the point, because I think I agree with
you.
Eric Ridgeway
Agreed it won't get you all the way there ... but is certainly part of the path .... the one goal every master should have for his/her student would be that they one day surpass the master .... this is the greatest gift you can give your teacher ....
I do apply a lot of what I learn from bonsai to software .... many things fit together
George Dinwiddie
Thanks, I think you do, too.
- George
Ralf Westphal
a materly piece of software?
If we look at buildings, we can tell if they´ve been build by masters.
If we look at a table, a painting, a garden, a bonsai tree: We can
tell, if they´ve been "made" by masters.
I say: Let the workpiece speak for its maker. Let the workpiece tell
us, if he/she is a master or an apprentice or somewhere in between.
If we´ve criteria for telling masterpieces apart from crap for
buildings and paintings, what are the criteria for software?
Edward Gabriel Moraru
Edward Gabriel Moraru
Kurt Häusler
read Uncle Bob's latest post where he frames craftsmanship as being
something to do with avoiding crap.
And then I was trying to reconcile that with the concept of
craftsmanship being a journey where we continually improve but never
reach the destination.
The first picture that formed in my head was the idea that all
software is crap, and a software developer spends his whole life
trying to write less and less crappy code, never quite reaching the
mythical destination of adequate, crap free software. I felt depressed
by that vision.
For me avoiding crap seems a pretty low bar. I think not writing crap
is an easy achievement that any programmer should get a handle on
early in their career. I suppose it depends how we define crap. I
suppose one definition could be any software whose total cost
including maintenance cost, and costs imposed by it on other
activities outweigh the benefits that the code provides. Another
definition is a little bit less objective, but could be something like
free of anti-patterns. Even more subjective, crap code is anything
that someone should either be fired for or not receive payment for.
It is like defining the medical profession around a central goal of
having less patients die due to incompetence.
You don't need a lifelong journey of craftsmanship to avoid writing
crap software. Not writing crap is (one of) the first steps along a
software developer's journey, and I don't think it is that hard. (And
I think it should be easy to identify crap, and even to certify
someone as having the ability and skill to write software that is not
crap, but that's a touchy subject)
I don't think there is a simple dichotomy between crap and
masterpieces, once you stop writing crap you are writing adequate
code, experience might lead one to write even better code. That is the
real journey.
I am quite happy with the concepts of "master craftsmanship" and
"software masterpieces" being mythical, unreachable things, approached
but never arrived at. Perhaps that is what software craftsmanship
should be, mulling over this vague vision of mastery, and making steps
towards it. I am quite happy with the idea that mastery can never be
certified, and there being no criteria for determining what is a
masterpiece and what is not.
But avoiding crap isn't a very exciting vision for me, in fact
avoiding crap seems to me to be the bare minimum competence for any
professional software developer, and certainly placed near the
beginning of a developers journey (ideally before they start thinking
about craftsmanship) rather than a central orienting goal for the
craftsmanship movement.
Avoiding crap is nothing to strive for, it is the baseline. Let us
strive for mastery instead.
Lawrence Fitzpatrick
Zinsser, if i could be forgiven for over simplifying, focuses on technique to achieve clarity and parsimony.
Clarity - is the writing optimally understandable and faithful to it's intent?
Parsimony - does it say only what it needs to say and no more?
He outlines a bunch of techniques.
In effect, he describes a process of continuous editing. We, in software, talk about writing and refactoring (rewriting), but rarely if ever have I heard the word editing.
Indeed, we too often declare 'done' when it compiles, passes it's meager test suite, phenotypically appears correct. What about the other -ilities? Maintainable, understandable, robust, ...
Lawrence Fitzpatrick
240-876-1325
Computech, Inc