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

 

Fri, 29 Apr 2005

Ralph Johnson on Learning Langauges and Finding Experts

Pat posted a gem from the Domain-Driven Design yahoo group. Ralph's advice ties directly into Find Your Master and Your First Language, two of the apprenticeship patterns I'm fiddling with.

My favorite nugget of wisdom from Ralph...

"By far the best way to learn a language is to work with an expert in it. You should pick a language based on people who you know. One expert is all it takes, but you need one."
This alters my direction on the Your First Language pattern. I had been wanting to advocate starting with dynamic languages because they help tie into the Short Feedback Loops pattern. Ralph's advice helps me see that the attributes of a language are not the only way to shorten feedback loops.

The availability of the feedback of a nearby language expert should be a major factor when selecting Your First Language.

[/links] permanent link

Wed, 27 Apr 2005

Apprenticeship Pattern: Study the Classics

"Discover the great literature in your profession or area of interest -- the finest books, articles, and speeches ever written -- and then begin an earnest study of these works." --Joshua Kerievsky, Knowledge Hydrant
As a software craftsman on the road to becoming a journeyman, study the classics of software development. Find the books that have remained relevant decades after publication. Search for source code of successful projects. Solicit and gather reading recommendations from more experienced developers.

Steve McConnell wrote in Code Complete,

"If you read even one good programming book every two months, roughly 35 pages a week, you'll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you."
Steve's finding is sad, and too often true. Just a bit of interest, a hint of passion for your craft, and you will likely find yourself standing out. You are outgrowing your organization. To continue on your path toward becoming a journeyman, look to create or join a team on which you can Be the Worst.

The key phrase in Steve's quote is "good programming book". There are an amazing number of programming books out there. Distinguishing the good ones is a critical skill because reading the right book at the right time is priceless.

Joshua Kerievsky once asked Jerry Weinberg how he keeps up with all the books that come out. Jerry said, "Easy -- I only read the great ones." Find the great ones. This is the first step to studying the classics.

[/craftsmanship] permanent link

Thu, 21 Apr 2005

From Perl to Ruby

Sam wrote about bridging the gap between Java and Ruby. Chris commented that Ruby doesn't just compete with Java, it also competes with its forefather Perl...
"...while Ruby is cleaner than Perl it's not really that different -- they're niches are much the same."
Other than the spelling error, this sentence makes sense to me. My first language was Perl (a secret I've successfully hidden from many Java-bigots).

Over the last 6 weeks I've been writing Perl full-time for my client, a financial trading firm in Chicago. This has been great fun as I've been able to reintroduce myself to the wealth of CPAN and the power of Perl (in contrast to the verbosity of Java). If I had my choice, though, I'd be writing Ruby. While Chris is right that there are many similarities between Perl and Ruby, the differences between OO Perl and Ruby can't be understated.

Like Chris, I doubt there will be a big migration from Perl to Ruby anytime soon. One reason for this is that Perl is everywhere. This is one of the reasons why I've been writing Perl for the last six weeks. Perl is already installed on every server (Windows and *nix) in the company, while there are only a handful of people here that have even heard of Ruby.

Rails is bringing more attention to Ruby. But I don't think that Ruby is going to gain a significant mindshare advantage until someone produces a groundbreaking IDE for it. That is something that Java developers are accustomed to and dynamic language folks have always coveted (with exceptions).

[/links] permanent link

Fri, 15 Apr 2005

Looking for Stories of Young Apprentices

Today I had the pleasure to have a long IM conversation with Steve Baker, a young bluenoser who, after 14 years of programming, still considers himself an apprentice. It was an enlightening conversation. Steve had a lot of ideas about the apprenticeship pattern language I'm developing and many of his stories tied together several of the patterns.

The theme of the conversation was the idea that someone can be an exceptional programmer (relative to the industry) and still consider himself an apprentice (compared to a master craftsman). This concept cuts across several of the apprenticeship patterns, but shares the most with Accurate Self Assessment.

Anyway, I'm looking to speak with other people who consider themselves to be apprentices. Particularly young people. I'm targeting these patterns at teenagers and college students. I want to hear about the stories of young apprentices as they're living them out.

So if you know if anyone who fits that description, please have them contact me.

[/craftsmanship] permanent link

Thu, 14 Apr 2005

A Thread of Patterns (upon further review)

Pat notes that the sequence of the thread of patterns that I threw together didn't fit for him chronologically. This made me realize that I didn't intend for them to be read chronologically. I sort of just arbitrarily threw them together and wrote about them in that sequence.

The next time I do that, I'll put a bit more thought into the ordering. It really should be chronological, as Pat assumed.

[/links] permanent link

Wed, 13 Apr 2005

A Thread of Patterns

I learned about pattern sequencing in Organizational Patterns and thought I'd try out the idea on the software apprenticeship pattern language I'm playing with. Here's a first pass at stringing a few of the patterns together...
  Find Your Master -> Be The Worst -> Accurate Self Assessment -> Expose Your Ignorance
To become an exceptional software developer, a master craftsman, you are going to need to work closely with exceptional software developers. Your desire to become a master craftsman implies that you recognize that you are not yet a master craftsman. Recognize this, dwell on this, anticipate the long road ahead of you.

Now begins your quest: you must seek out a master to apprentice under. For an exceptionally few people, this quest will result in a formal master/apprentice relationship. For the rest of us, this quest will become a series of relationships, as masters come and go with assignments, jobs, and contexts. Seek out the exceptional developers in your area and make contact.

Along the way, reflect on the teams and projects you are affiliated with. Would you consider yourself the worst developer in these contexts? If you are lucky enough to answer in the affirmative, congratulations, you are in an excellent position. Not only are you surrounded by people who you can learn from but you possess the humility to capitalize on your situation.

If you find yourself in the position of being the best developer on your team, either start looking for a new team or work to bring in more senior developers. While being the best is flattering and can build confidence, your rate of learning will diminish. Even worse, a lack of oversight by master craftsmen or journeymen increases your liklihood of falling into bad development habits.

Becoming a master craftsman requires that you maintain an accurate assessment of your abilities as you work your way through your apprenticeship. While believing that you have achieved greatness makes it easier to justify your paycheck, it will only hinder you on your quest. You must expose yourself to exceptional developers in order to keep your ego in check and cultivate your humility. Even if you succeed in working side-by-side with a master craftsman, continue seek out other masters: in articles, books, mailing lists, and blogs. Appreciate how far you have to go.

To maintain an accurate assessment of your abilities, resist the natural instinct to hide your many zones of ignorance. You may have in-depth knowledge into a few threads of technology, but a master has the ability to weave a tapestry out of myriad threads. By embracing and exposing your ignorance, you will spin the missing threads much more quickly.

[/craftsmanship] permanent link

Fri, 08 Apr 2005

Ignore Your Title

I'm still playing around with the idea of writing about the software craftsman's transition from apprentice to journeyman. A book aimed at recent graduates, college students, teenagers, late-blooming software development converts (me), or long-time developers who find themselves stuck in a rut. For now, I've got a private wiki that I'm using to organize my ideas into an attempted pattern language. I'm going to use my blog and my StickyMinds column as places to grow my thinking on this topic and hopefully solicit some feedback.

This post is about one of the lower-level patterns that I'm fiddling with: Ignore Your Title...

Being hired or promoted into positions with titles that contain words such as lead, senior, or architect is an excellent feeling. Don't be fooled, though. These titles and responsibilities do not indicate that your apprenticeship is over. They should only serve to remind you that there is a shortage of craftsmen in our industry.

Your title will rarely reflect your level of craftsmanship. Do not allow your title to discourage or encourage you. It is a distraction, an annoyance that should be kept on the outskirts of your conciousness. Use it to gauge your organization, not yourself.

[/craftsmanship] permanent link

Fri, 01 Apr 2005

Ping-Pong Programming in Better Software

Rachel wrote an excellent article about pair programming in this month's issue of Better Software. I was interviewed about ping-pong programming for a sidebar to the article.

[/xp] permanent link


powered by blosxom