Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover

All [Atom]
Craftsmanship [Atom]
Dynamic [Atom]
Intersection [Atom]
Learning [Atom]
Links [Atom]
Polyglot [Atom]
Projects [Atom]
XP [Atom]
Old Blog

Obtivian Blogs

Andy Maleh
Colin Harris
Fred Polgardy
Jim Breen
Kevin Taylor
Todd Webb
Turner King
Tyler Jennings


March 2009 (1)
January 2009 (1)
December 2008 (1)
October 2008 (3)
September 2008 (1)
June 2008 (4)
April 2008 (3)
March 2008 (1)
February 2008 (1)
August 2007 (1)
July 2007 (1)
June 2007 (1)
May 2007 (4)
April 2007 (3)
March 2007 (5)
February 2007 (6)
January 2007 (6)
December 2006 (10)
November 2006 (5)
October 2006 (8)
September 2006 (8)
August 2006 (5)
July 2006 (12)
June 2006 (7)
May 2006 (5)
April 2006 (5)
March 2006 (4)
February 2006 (2)
January 2006 (5)
December 2005 (5)
November 2005 (3)
October 2005 (3)
September 2005 (6)
August 2005 (4)
July 2005 (7)
June 2005 (14)
May 2005 (6)
April 2005 (8)
March 2005 (9)
February 2005 (11)
January 2005 (16)
Old Archives


Wed, 29 Jun 2005

The Long Road and Practice, Practice, Practice

We've pushed out two new drafts of the apprentice patterns: As always, we're relying on feedback to shape the direction we take with these first drafts. Thank you to everyone who has provided feedback via comments, blog entries, hallway conversations, IM, etc.

[/craftsmanship] permanent link

Draw Your Own Map

We just pushed out Draw Your Own Map, rounding out the The Long Road family of patterns (as they're currently organized). This pattern has a different format and we would appreciate any feedback on that, as well as the pattern itself (comments are enabled on the page).

[/craftsmanship] permanent link

Fri, 24 Jun 2005

van Wijngaarden's Plea

Thank you to Kent Schnaith for encouraging me to read Dijkstra's 1972 ACM Turing Lecture, The Humble Programmer. I am inspired by Dijkstra's story of the critical moment when he was deciding between theoretical physics and programming as a student at the University of Lieden...
Full of misgivings I knocked on van Wijngaarden's office door, asking him whether I could "speak to him for a moment"; when I left his office a number of hours later, I was another person. For after having listened to my problems patiently, he agreed that up till that moment there was not much of a programming discipline, but then he went on to explain quietly that automatic computers were here to stay, that we were just at the beginning and could not I be one of the persons called to make programming a respectable discipline in the years to come?

[/craftsmanship] permanent link

Thu, 23 Jun 2005

Speaking of Narrative Therapy

I was invited by Tim to help out with a workshop at XP2005 about teams and teamwork. Tim asked me to talk a bit about narrative therapy, the method of family therapy that I focused on in graduate school.

This was a surreal invitation for me.

From the first time I read about the relationship between Virginia Satir and Jerry Weinberg in The Psychology of Computuer Programming I've been interested in introducing ideas from narrative therapy into software development. And from the first time I felt a familiar philosophical foundation in Extreme Programming Explained, I've been interested in introducing ideas from narrative therapy into the agile community. My problem has been that I don't have enough experience in either software development or therapy to do an effective job of integrating them. Fortunately, I didn't realize this at first, and I ended up encouraging a few geeks to read Narrative Therapy: The Social Construction of Preferred Realities.

Anyway, similar to my last public speaking experience, I was pretty much a disaster, a bumbling, fumbling, jumble of words stopping and starting as my thoughts abandoned me. I had hoped for a smallish group and was pleased to have nine people attend the three hour session. Laurent and Ivan popped in for a while. Steve Freeman, Rachel Davies, Vera Peeters, and Michael Feathers were among the excellent group of attendees who stuck with me and began asking the insightful questions that got me back on track. I'm excited to hear what they take away from the book.

Thank you Tim for giving me such an excellent opportunity.

[/intersection] permanent link

Mon, 20 Jun 2005

XP Declared Not Trendy; Please Move Along

Jutta Eckstein gave the keynote at XP2005 tonight. She declared that XP and Agile Development are no longer trendy (they've reached the beginnings of maturity) and that the trendsetters should probably move onto something else.

I agree. But this begs the question: Where do they go? I hope that they go where Uncle Bob thinks they will go: onto Software Craftsmanship.

[/xp] permanent link

Out of America; Old Friends, New Friends

I flew into Manchester yesterday morning, caught a train to Sheffield, and showed up at the University in time to meet Laurent, Emmanuel, Uncle Bob, Liz, and Tim, for the Coder's Dojo workshop [PDF], which was marvelous. Uncle Bob wrote an excellent write-up.

Alan was lurking about in the hallways wearing a Mac OS X t-shirt that he later gave to me as a gift. Thanks dude.

[/xp] permanent link

Thu, 16 Jun 2005

Stories from Micah, an Email from Pam

Micah Martin, son of Uncle Bob (does that make Micah a cousin?) has posted two interesting blog entries. One of them answers a few questions I asked Micah, and one is a tale of two apprentices.

Pam Rostal contacted me to let me know that she is part of a community working on pedagogical apprenticeship patterns and androgogical approaches to learning in agile software development teams (wiki). This stuff excites me because it appears to be synergetic with what I'm working on. While our apprenticeship patterns are written to apprentices, Pam's work looks like it's aimed at educators and masters. To see software craftsmanship being pushed from multiple levels is encouraging!

[/links] permanent link

Wed, 15 Jun 2005

Liz Keogh on Resisting the Promotion

Liz weighed in with her thoughts on Resist the Promotion, suggesting a new pattern Step On Up. I like the idea, and while it could be described as a pattern of software craftsmanship, it's not a pattern for apprentices. But let me defer that issue for now. My assertion might make more sense after I address the concept of apprenticeship. (see below)
Liz: "Dave says that he's aiming his patterns at new programmers, but I've found that a great deal of them are applicable to where I am in my career."
When I started writing the apprenticeship patterns, I was explicit with myself about the target audience: novice programmers interested in software craftsmanship. I received feedback early on from my brother (a user experience designer at Microsoft) that some of the patterns could be made more abstract because they were applicable outside of the domain of software craftsmanship. Since then, I've had programmers with more than 15 years of experience tell me that they found the patterns relevant. While this feedback is encouraging, we are going to continue to keep our context grounded in novice programmers.
Liz: "I don't feel as though I've finished my apprenticeship yet, despite having over seven years of industry experience.
According to Pete McBreen, "An apprenticeship will last at least five years" (Software Craftsmanship, p. 102). The context of Pete's statement implied that the apprenticeship followed the ideals set out in his book. In other words, apprentices work on a small team of craftsmen, consisting of other apprentices, a few journeymen, and a master. It's safe to say that most of us didn't have the benefit of such an environment during the first five years of our careers, nor for any 5 year stretches of our careers. So it's not surprising that Liz's apprenticeship continues, as does mine.
Liz: "I accept that it's important to understand the technical aspects of the job in depth, and therefore resisting a promotion is important, but I feel it's equally important to recognise the point at which you as a developer can move on to help facilitate the process which turns ideas into reality."
True, but one must wait until your apprenticeship is over. Resist the Promotion is written for apprentices because it is during apprenticeship that a craftsman's knowledge is most transient. A journeyman or a master might be able to maintain their craftsmanship for a season when they've found it appropriate to Step On Up, but an apprentice will lose his expertise much more quickly.
Liz: "Apprenticeship has to be a life-long pursuit; a journey towards an unreachable destination, but an important journey nontheless."
Liz is confusing apprenticeship with mastery. For the purposes of the apprenticeship patterns, I am basing my understanding of these concepts on Software Craftsmanship by Pete McBreen and Mastery by George Leonard. While an apprenticeship does, in fact, have an ending, the path to mastery does not. Although we haven't yet come up with a clear distinction between apprentice and journeyman, we are operating under the assumption that they are two distinct stages of the software craftsman. In my opinion, what Liz is describing is mastery, not apprenticeship.
Liz: "Dave and Pat, if you read this; I'd be interested to know if this makes any sense to you. From my point of view, you're masters. Do you consider yourselves to have finished your apprenticeships yet?"
I don't understand how you could think either Pat or I are masters. You've never worked with us. And no, I have not yet finished my apprenticeship. I've been programming for less than five years.

Update: Liz, I definitely was not annoyed with you, no apology necessary. I appreciate you and Pat posting on this topic because it's forcing me to clarify the pattern. It's exactly what I needed and I hope that you'll continue to comment, critique, and suggest alternatives. Pardon the tone of the blog entry, it's probably the outcome of me trying to do too many things at once.

[/craftsmanship] permanent link

Tue, 14 Jun 2005

Patrick Morrison on Resisting the Promotion; I Emphasize the Context

Pat has provided some feedback on Resist the Promotion. Pat rightly points out...
I think that the really great engineering projects cannot be accomplished with technical talent alone, nor can they be accomplished using managers who are not also technical.

There is a vital need for managers who know technology, deeply. This need can only be supplied 'from the ranks' of those who are technical.
I completely agree. It seems that Pat has not only taken Resist the Promotion out of context, he has converted it into a context-less principle. As if Ade and I were saying that all programmers were making a mistake to move into management.

In an attempt to avoid further confusion, I will address what these apprenticeship patterns are trying to accomplish and who they are written for.

These patterns are an attempt to distill concrete, practical advice from the ideals presented in Pete McBreen's Software Craftsmanship, from our own experiences, and from the experiences of the apprentices we are interviewing. Pete's book presents a vision of the field of software development that has inspired many craftsmen, myself included. Yet Pete's book is targeted at an audience that has the power and ability to take on apprentices. I wanted to write something for the apprentices themselves. We believe there is a need for a book that helps aspiring craftsmen navigate an industry that does not embrace the craftsmanship mindset. These patterns are written for new programmers who aspire to become master craftsmen.

Tying this back into Pat's feedback, let me state clearly that the pattern is not asserting that there is anything inherently wrong with a programmer accepting a promotion into management. In fact, for those who aspire to become great technical managers, it can make perfect sense to accept the promotion. That said, the implicit context of all of these patterns is that you are an inexperienced programmer who desires to become a master craftsman. The explicit context of Resist the Promotion is that you are being offered a promotion that would have you spending less time programming. In that context, we have found that for apprentices to stay on the path to mastery, it is necessary to resist the promotion in order to continue programming full-time.

[/craftsmanship] permanent link

Sun, 12 Jun 2005

Bernard Notarianni on Resisting the Promotion

Rather than commenting on Resist The Promotion, Bernard used his blog to provide feedback, leaving the URL to the blog post as a comment. I prefer this idea over putting the content in the comment form because it exposes the patterns to a wider audience.

Regarding his feedback, it resonates with a conversation I had with former programmer Ross Petit, the ThoughtWorks account principal on my current project. We were discussing Resist The Promotion and Ross pointed out something similar to Bernard. As you progress toward mastery, your vision of the development lifecycle expands. Take for example one of my teammates, Paul Hammant. He operates at multiple levels of the project, all the while remaining intimitely involved with the lowest level code. As Bernard put it:

For sure, those tasks are not programming, but maybe, a master has the ability to keep an eye on all of them, at the same time, and drive them into the right direction to enable the programming task to happen in the best possible context.

Hence, for sure you must resist for promotion if accepting it will put you away totally of programming, but maybe, you could be at a sufficient level to keep doing it, while addressing more managerial tasks.

By the way, I'm not implying that Paul is a "master". How would I know that? I just know he's further along the path that I am walking on.

In response to Bernard's feedback, I should also point out something I have had to point out other collaborators previously. These patterns are specifically for apprentices. Resist The Promotion is not written for journeymen or masters. While some of the apprenticeship patterns might apply to craftsmen at all levels, there are some that are inappropriate outside the context of apprenticeship. Which ones? You tell me.

[/craftsmanship] permanent link

Sat, 11 Jun 2005

Apprentice Pattern: For Love Not Money

I just pushed out another pattern: For Love Not Money. I'm not satisfied with it, but I wanted to get it out there for feedback.

Thanks to Dave Astels, Christian Taubman, and Kent Schnaith for their feedback on Accurate Self Assessment and Nurture Your Passion.

I'm planning on working on The Long Road next, in hopes of pulling that family of of patterns together for a sample chapter.

[/craftsmanship] permanent link

Thu, 09 Jun 2005

Liz Keogh's Apprentice Story

Liz posted some lessons she's learned during her time as a software developer. It's reassuring to see some of the common patterns of successful apprenticeships echoed in Liz's story. I particularly resonated with her lesson about reading lists and her love for books (hello Bookshelved).

Also, I just pushed out another pattern: Nurture Your Passion. I would love to get some feedback on it (use the comment form).

[/links] permanent link

Mon, 06 Jun 2005

Ping-Pong Programming on

I blogged about Ping-Pong Programming in January. That blog entry has morphed into an article on

[/xp] permanent link

Sun, 05 Jun 2005

The Patterns Progress

The apprenticeship patterns continue to grow as Ade and I slowly gather feedback from craftsmen around the world. I'm having a great time with this.

Steve Baker posted his apprentice story, focusing on Be The Worst.

The Paris XP Practitioner's Group used their May 26 meeting to discuss the apprenticeship patterns. Laurent submitted a few patterns, my favorite was Primary Sources.

People have been asking us to share more than just the pattern names, so I whipped up a Ruby script that will publish the patterns we think are ready for public feedback. See what we've put out there on the patterns page. Comments will be coming soon.

Update: I've added comments to each of the pattern pages.

[/craftsmanship] permanent link

powered by blosxom