Red Squirrel Reflections
Dave Hoover explores the psychology of software development

Dave Hoover
dave.hoover@gmail.com

Categories
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

Archives

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

 

Sun, 22 May 2005

Looking for The Quality Without a Name

In preparation to continue our work on the apprenticeship pattern language, I'm reading Christopher Alexander's The Timeless Way of Building, the book that precedes A Pattern Language. The Timeless Way focuses (so far) on the Quality Without A Name. Whether any of the apprenticeship patterns that have emerged thus far capture this quality is yet to be seen, but I know that there have been specific times during my apprenticeship when I have experienced what Alexander describes.

I have experienced this self-sustaining wholeness when I have read The Right Book At The Right Time as a result of Constructing My Curriculum. This wholeness comes when the ideas in the book are directly relevant to what I am learning in practice, or when they tie together in theory what I have read in more practical books that vary across time and subject.

I have experienced this self-sustaining wholeness several times since leaving my previous employer. My Accurate Self-Assessment informed me that I was a novice, and yet it was becoming difficult to Ignore My Title because I had quickly surpassed my co-workers. As I sought to Be The Worst I found my way to ThoughtWorks. Being a ThoughtWorker has allowed me to apply more of these apprenticeship patterns than anywhere else.

And hooking together patterns is at the center of the Quality Without A Name...

"The quality without a name appears, not when an isolated pattern lives, but when an entire system of patterns, interdependent at many levels, is all stable and alive." p. 131

[/craftsmanship] permanent link

Fri, 13 May 2005

The Ruby White Belt

One of the attributes of some of my favorite patterns books are visual representations of the relationships between the patterns. Particularly Domain-Driven Design and Organizational Patterns of Agile Software Development. Therefore, I want to be able to easily generate a visual representation of the apprenticeship pattern language.

Taking a cue from Jim Coplien's OrganizationBookPatternTable and corresponding OrgPatternsMap, I started a page on my private wiki that mapped some of the dependencies for Accurate Self-Assessment. I then began developing a Ruby script to grab my wiki page, parse it, and convert the patterns into dot format, which I would then pipe into dot to create something like this

And it was all going very smoothly until I needed to use a regular expression to grab all the instances of a specific regexen from a single line. In Perl this is accomplished like this:

	$line = 'Mac Mini, 1.25GHz $499.00 1.42GHz $599.00';
	@prices = $line =~ /\$(\d+)/g;
The @prices array contains 499 and 599. Perl and Ruby are so similar, I assumed it would be easy to do the same in Ruby. I tried /\$(\d+)/g and Ruby told me g was an uknown regexp option. I scoured the Regexp and MatchData docs but came up with nothing. I pinged a couple Rubyists on IM and I was told that to do the same thing in Ruby, I would need to use String.gsub, which is odd, since you're not actually substituting anything. Here's the eqivalent Ruby code.
	line = "Mac Mini, 1.25GHz $499.00 1.42GHz $599.00"
	prices = []
	line.gsub( /\$(\d+)/ ) do
		prices.push($1)
	end
Bletch. I was disappointed. How could a language as beloved as Ruby fall down on such a fundamental text-processing task?

And then I pondered an apprenticeship pattern that Ade drafted yesterday: Wear the White Belt. A key thought from the pattern:

"We have to be able to put aside our past experiences and preconceptions to allow in new knowledge."
Determined to Wear the White Belt, I went back to the documents once more, this time not trying to translate my Perl approach into Ruby, but to learn the Ruby way. And surprise, surprise, I found String.scan. Now this is what I've come to expect from Ruby...
	line = "Mac Mini, 1.25GHz $499.00 1.42GHz $599.00"
	prices = line.scan( /\$(\d+)/ )

Ahhhh, the power of Perl combined with the elegance of Japanese design. Hold onto that white belt.

[/craftsmanship] permanent link

Mon, 09 May 2005

Initial List of Apprenticeship Patterns

I have recieved pattern suggestions and submissions from a number of people, including Marten and Adelwale. I think it would help to offer a glimpse into the state of the pattern language. I've posted an initial list of the patterns here: http://redsquirrel.com/dave/work/a2j/.

Or to be more accurate, I wrote a Ruby script to scrape my personal wiki and post the patterns publicly. :-)

[/craftsmanship] permanent link

The Power of Attentiveness

I asked an apprentice from the southern hemisphere to tell me stories about her best pair programming experiences. It turns out she writes well and had a few excellent stories. One of her stories doesn't apply directly to apprenticeship so I am posting it now with her permission (and names changed). I feel that this story is more applicable to journeymen and master craftsmen than apprentices...
I asked Robert to pair with me when refactoring some tests a month or so ago despite being pretty nervous to do so. It turns out it was one of the best pairing experiences I have had. I did learn quite a bit technically, but on a people skills level I was totally astounded. Even though it did take a few days for my brain to realise what Robert had actually done or rather facilitated.

The funny thing is that I can not describe in particular what it is that Robert taught me. What I got from it was the desire to develop the soft skills which were demonstrated so naturally, perhaps without him even knowing it. He made me feel good about my programming even though my experience in comparison pales. For the first 15 minutes I was pretty terrified pairing with him. Consequently in those 15 minutes I was not really that effective.

It is not that he explicitly encouraged me, he listened to what I had to say. He re-evaluated the decisions he had made after hearing what I said. And the more I felt good about everything, the more I had to say and the more useful I was. He didn't let me get away with not knowing what was going on, as soon as he saw that the keyboard was passed over to me. If I didn't understand, it was because the code that we were writing was not self documenting. We renamed. We refactored. And I understood. Most importantly though, I really felt in tune with Robert and what we were doing. I was feeling good and having fun.

I have just re-read the above paragraph over again and I still don't think I've described what exactly I am trying to. Basically Robert's ability to pair with someone and really make them feel as though they are contributing, and always picking up on any subtle "broken connection" between the pair and not moving on until we were both again in step was phenomenal. I think that is probably the most productive (and mentally tiring) yet completely rewarding pairing that I've done. I think this ability holds just as much water as technical skill, in fact I think it holds more.

It was an awesome experience.

[/craftsmanship] permanent link

Thu, 05 May 2005

Apprenticeship Pattern: Accurate Self-Assessment

"For everyone who exalts himself will be humbled, and he who humbles himself will be exalted." --Luke 14:11
If the metaphor of software craftsmanship is to leak out into the consciousness of the software development industry, individuals need a means of assessing where they are on the path from apprentice to journeyman to master craftsman. I can't imagine an objective way to handle this assessment. For me, and for many other aspiring craftsmen, it is a gut feeling, an evolving self-perception that grows more distinct as we walk The Long Road to mastery.

For the few fortunate developers that work under the formal supervision of master craftsmen, maintaining an Accurate Self-Assessment is as simple as sitting down periodically with their mentor and reviewing their progress. The rest of us must pull our mentoring out of books, blogs, online communities, local user groups, peers, and from project-to-project. Maintaining an Accurate Self-Assessment becomes a much more proactive and rigorous activity. Some of the patterns that facilitate this activity include Be the Worst, Expose your Ignorance, Find your Master, and Kindred Spirits.

Many apprentices find that as they walk the path toward journeyman they begin surpassing their more experienced cohorts. For some, they will eventually find themselves in leadership positions with impressive words in their titles such as architect, senior, and engineer. This phenomenon is a threat an Accurate Self-Assessment. Software craftsmen, particularly apprentices, must be careful who they compare themselves to: a craftsman's progress should be assessed relative to master craftsmen, not the industry average. The implications of this is that there are team leads, architects, and senior developers who still consider themselves apprentices. Maintaining an Accurate Self-Assessment allows apprentices to Ignore their Title and continue on The Long Road.

Humility is at the heart of apprenticeship, specifically this pattern. The early successes that many software developers experience can destroy the humble attitude that a successful apprenticeship requires. Jerry Weinberg describes the road to mastery as plateaus, ravines, and steep inclines. As the apprentice reaches new plateaus she must maintain her humility, it is far too easy to become impressed with our ever-growing abilities. From Becoming a Technical Leader...

"I can still remember how splendid it felt to be the best IBM 650 programmer in San Francisco, more than a quarter-century ago. This is the typical feeling in the middle of the plateau stage -- smug satisfaction." p. 42

[/craftsmanship] permanent link

Buried in Apprentice Stories and Laughter

I have been encouraged and enriched by the many people who have collaborated with me thus far on the apprenticeship pattern language. I've had an excellent response from several people within ThoughtWorks as well as other craftsmen across North America and Europe (I'd really love to hear from craftsmen on other continents). People like Marten Gustafson, Dave Astels, Ken Auer, and Adewale Oshineye. Much thanks to everyone. It's starting to hit me how much work lies ahead.

I'm up to my eyeballs in stories to harvest, but I thought I'd share one snippet from Matt Savage:

"I sometimes wonder if I'll ever stop laughing at code I produced 6 months ago."
I've had this experience more times than I can remember. Apprentices should experience this laughter regularly. What I've noticed since joining ThoughtWorks is that the laughter cycles have shortened. I was laughing at the code I wrote 3 months ago within 4 months of joining ThoughtWorks. This laughter metric is an excellent indicator of learning, of progress on the path from apprentice to journeyman.

[/craftsmanship] permanent link


powered by blosxom