Red Squirrel Reflections
Dave Hoover explores the psychology of software development
Sun, 22 May 2005apprenticeship 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
Fri, 13 May 2005Domain-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) endBletch. 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.
Mon, 09 May 2005Marten 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. :-)
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.
Thu, 05 May 2005
"For everyone who exalts himself will be humbled, and he who humbles himself will be exalted." --Luke 14:11If 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. 42ThoughtWorks 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.