Identity of the Craftsman (Mailing List)

[Sukant Hajra]

This thread is a spin-off of all the recent threads that have been boiling
over, largely in response to postings by Jason, with whom I'm mostly in
agreement with.


What I like about the Software Craftsmanship community
------------------------------------------------------

I want to be around people that cherish their craft. But just saying, "I want
to hang out with people that care" is way too open-ended. At least with this
group, I feel a kindred spirit in how we advocate

- light-weight processes of some old-school Agile-ish flavor

- the kinds of recommendations one might find in seminal books by Beck,
Fowler, Hunt, Martin, Thomas, and others

- behavior-driven design where appropriate

- and so forth (I really don't want to get too caught up in the specifics).

I'm not sure who's behind the on-line manifesto [1]. I suspect it's 8th Light,
because "softwarecraftsmanship.org" is their domain. Over all, I'm completely
in line with the manifesto.

[1] http://manifesto.softwarecraftsmanship.org/


The Stuff of Controversy
------------------------

But then there's McBreen's book. First off, it's got the title, right there --
"Software Craftsmanship", which makes it seem like a bible of a movement. I
feel some people have adopted it as such.

But McBreen's prose goes much farther than the airy constraints of the
manifesto. There's real assertions, if not a thesis there. First off, there's
his attacks on "engineering," which are tedious and provoke semantic battles
over what "engineering" means, has meant, or should mean.

Then there's The Metaphor. It's cute, and it certainly highlights a problem.
But to stratify all of us into three, count them /three/, categories --
apprentice, journeyman, master -- is destined to be fraught with inadequacy.

I love the journeyman idea. That's a call to action. The craftsman must
journey. That seems clear to me; if you sit in the same place for two long,
you risk limiting growth. And it's important to journey to places where the
benefit to employer and employee is mutual.

But when it comes to "mastery," there's /way/ too many things to master in
software from algorithms, to distributed computing, to language design, to
testing, to infrastructure. People will have different proficiencies in
different areas, and that's that. It's really up to the hiring party to assess
value through an interview process.

As for "masterpieces," we all have code that represents the state of our art.
I guess if I had been the sole architect of some great open-source framework, I
might call it my "masterpiece" but it would be tongue-in-cheek at most. And
even if I had such a body of work, I'd still encourage a hiring company to
interview me aggressively enough to make sure I met their needs appropriately.
Barring some compromises of really bad economic times, I'd certainly be
interviewing them too to make sure they met my needs.

The masterpieces, the time spent learning, the variety of learning
environments. . . it's all just supporting evidence. There's no absolute
proof. So let's just let it go. Anyone whose best argument about their
mastery is because some other guy says so is participating in the same nonsense
that say that a college degree is worth something by name alone.


Where Do We Stand?
------------------

Okay, so we have:

- the manifesto
- the body of discussion in this Google Group
- McBreen's book
- the metaphor
- anything else? What else advises the identity of this group?

The manifesto nicely asserts that a craftsman values community. This Google
Group works well to bind that community.

Do we as a community really need to be so strongly bound by the ideas in
McBreens's book or the metaphor? Is McBreen even on this list? I wonder what
his response would be to all this.

-Sukant

[Mark Nijhof]

I would add a few more books:

- Pragmatic Programmer, Andrew Hunt and Dave Thomas
- The Passionate Programmer, Chad Fowler
- Apprenticeship Patterns, Hoover Dave and Oshineye Adewale

- Clean Code, Robert C. Martin

- The Craftsman, Richard Sennett

Also there are Software Craftsmanship Conferences as far as I know one
in the US and one in the UK

-Mark

> --
>
> 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.
>
>
>

[Jason Catena]

> But when it comes to "mastery," there's /way/ too many things to master in
> software from algorithms, to distributed computing, to language design, to
> testing, to infrastructure.  People will have different proficiencies in
> different areas, and that's that.

Agree. You're a master of one program, or programming style, or
programming process, or whatever. Master as a title is simply not
applicable across all of computer science, or all programming jobs, to
areas where you don't have experience. So I don't believe there's any
value in a certificate that says "master" without any qualifications.
Diplomas have majors, "mastery" claims should name languages or
programs or whatever, but at that point it's not much different than a
more elaborate certification program.

> As for "masterpieces," we all have code that represents the state of our art.
> I guess if I had been the sole architect of some great open-source framework, I
> might call it my "masterpiece" but it would be tongue-in-cheek at most.

I worked for ten years on a "masterpiece", reasonably worthy of the
title. Just about the time you put your finishing touches on it, you
go back to square one and reinvent all your methods. I'm relearning
basic coding and style, and it makes my previous approaches obsolete.
I was helped in this by a change in responsibilities, that force me to
get my mind out of a rut where I became the "master".

> It's really up to the hiring party to assess
> value through an interview process.

> And
> even if I had such a body of work, I'd still encourage a hiring company to
> interview me aggressively enough to make sure I met their needs appropriately.
> Barring some compromises of really bad economic times, I'd certainly be
> interviewing them too to make sure they met my needs.

This is exactly right, though "economic times" lead to more
compromises than you might imagine.

> -Sukant

Jason Catena

[cory...@gmail.com]

Hi Sukant,

I largely agree with many of the things in your email except one - the tie in of the movement to employability.

I don't strive to be a master for my resume. I may choose to master a skill to do work, but my journey in craftsmanship is not about getting a job.

When you look at crafters they are masters of specific things. I've learned this week of people who knit using wire. It's OK for us to have different areas, different masterpieces, etc. But a master in wood could probably recognize a master in knitting and have interesting discussions - because the medium is just an expression.

There are people in our craft I consider masters and who I strive to be like. But in the end, mastery is about the person, not a certification. That's the hard part - understanding that you can be the best compiler writer in the world, but unless you can mentor others and share that, you aren't a master.

It truly is all about the journey and the metaphor which reminds us to keep learning and stop putting up with crap.

--
Cory Foy
http://www.coryfoy.com
http://twitter.com/cory_foy
Sent from my Verizon Wireless BlackBerry

[Steve Tooke]

On Sun, Dec 13, 2009 at 8:50 PM, <cory...@gmail.com> wrote:
> I don't strive to be a master for my resume. I may choose to master a skill to do work, but
> my journey in craftsmanship is not about getting a job.

> ...

> It truly is all about the journey and the metaphor which reminds us to keep learning and stop
> putting up with crap.

Well put! The labels apprentice, journeyman and master aren't
destinations or even waypoints on the journey they're just signposts
pointing you in the right direction.

--
/tooky

[Sukant Hajra]

Excerpts from cory.foy-at-gmail.com |Software Craftsmanship/mailing_lists|'s message of Sun Dec 13 14:50:08 -0600 2009:

>
> I largely agree with many of the things in your email except one - the tie in
> of the movement to employability.

Ah, I got you. Interesting point.

I reread my post, and I think the problem is that many people outside of the
Software Craftsmanship community /will/ take concepts like "master" and
"masterpiece" in the context of some kind of accreditation, which I think we're
all clearly not all that interested in.

Most of the discussion on the last three threads has been more about this
external perspective, because I think there's far less conflict between those
inside the Software Craftsmanship circle.

> I don't strive to be a master for my resume. I may choose to master a skill to
> do work, but my journey in craftsmanship is not about getting a job.

That's great. I think a lot of us have that perspective.

However, there's a lot of skills that we have to pick up that are pretty much
unique to writing software as a career:

- sensitivity to customer requirements (making sure they are strongly
communicated with and often)

- testing in a way that ties code implementation to requested features

- iterative design and development to enable adaptability to a volatile
market.

My draw into software was really intensified with the burgeoning
accomplishments of FOSS projects. To this day, I'm amazed at the depth and
breadth of what's been accomplished by people coding out of passion in their
free time.

But FOSS isn't really all the Agile. Much of it isn't even tested, relying
more on bug reports to keep things straight. And as for iterative design and
development. . . I don't really see it to often. And yet FOSS does really well
considering it's goals and the competing interests.

What I'm really driving at is that a nontrivial set of Software Craftsmanship
practices assume that software is being written for a paying client. So in
that context, part of being a "master" is about having skills to survive in a
paying environment with time and resource constraints and possibly shifting or
immature requirements.

I just have a hard time shaking the idea that one can so cleanly separate the
"job" factor out of "craftsmanship." Perhaps, you're trying to say something
like "craftsmanship isn't about getting a job, but doing a job well." But
really, for me, getting a job /is/ about doing jobs well. Anything else is
duplicitous.

> understanding that you can be the best compiler writer in the world, but
> unless you can mentor others and share that, you aren't a master.

I really like this point.

> It truly is all about the journey and the metaphor which reminds us to keep
> learning and stop putting up with crap.

Okay, so this deals with the final section (and the subject) of my original
post: What value does this metaphor have for us and how does it impact the
identity of the group?

I like that you used a language like "reminds" us. Because it's softer than
"informs" us, and it's totally on the other spectrum from discussions about
reifying the metaphor.

If we all pretty much echo this kind of sentiment, I feel for this topic my
questions and concerns have been put to rest.

-Sukant

[Mark Nijhof]

> I just have a hard time shaking the idea that one can so cleanly separate the
> "job" factor out of "craftsmanship."  Perhaps, you're trying to say something
> like "craftsmanship isn't about getting a job, but doing a job well."  But
> really, for me, getting a job /is/ about doing jobs well.  Anything else is
> duplicitous.

For me Software Craftsmanship is about personal believes, so I don't
follow the path of software craftsmanship to get a better job, I do it
to get more satisfaction out of my job. I have a passion for it. But
in the end this would result in me being better at my job and thus I
could be able to get a better job (presumable). But that is not the
driver, I think if that would be the driver then you would fail at
being a software craftsman. I apply the same principles on software
development independent if it is a private project or a work related
project.

-Mark

[Sukant Hajra]

Excerpts from Mark Nijhof mark.nijhof-at-gmail.com |Software Craftsmanship/mailing_lists|'s message of Sun Dec 13 19:54:08 -0600 2009:

> I think if that [capitalistic gains] would be the driver then you would fail

> at being a software craftsman.

I feel I share a sentiment with you, but something about your assertion seems
kind of strong.

The discussion that I keep on coming back to on this issue is Jim Shore's
discussion in his Art of Agile Development book. On Figure 1-1 (page 5), he
draws a pretty simple three-circle Venn Diagram with the following labels:

- Organizational success
- Technical success
- Personal success

As expected, Shore puts a sweet-spot star in the intersection of all three, and
claims that we should strive to succeed in all these ways. Here's Shore's
discussion:

All three types of success are important. Without personal success, you'll
have trouble motivating yourself and employees. Without technical success,
your source code will eventually collapse under its own weight. Without
organizational success, your team may find that they're no longer wanted in
the company.

> I apply the same principles on software development independent if it is a
> private project or a work related project.

It seems you might be trying to assert that your definition of personal success
subsumes the other two definitions of success in a holistic way. Perhaps this
is a good standard for everyone who wants to be a craftsman.

Also, I'm assuming when you say "you apply the same principles" you're also
using a holistic set of principles that adapts to the context of the work
you're doing, in which case, you really won't be /doing the same things/ in a
private project you'd do in a work-related project. But both activities would
be informed by the same conversations.

I like this idea of a craftsman being guided by holistic principles that
promote success in all reasonable contexts, whether promoted by capitalistic
gain or not.

-Sukant

[Doug Bradbury]

On Dec 13, 2009, at 1:28 PM, Sukant Hajra wrote:
> I'm not sure who's behind the on-line manifesto [1].

This just made me realize how much this list has grown in size this year. The folks on this list are behind the manifesto. If you'd like a history lesson, take a look at these two threads:
http://groups.google.com/group/software_craftsmanship/browse_thread/thread/e23a276a46719935#
http://groups.google.com/group/software_craftsmanship/browse_thread/thread/8b2e4a48c02ee8d2#

126 message in all. And out the other end, popped the Manifesto for Software Craftsmanship.

Doug