Articles

I'm still thinking about Uncle Bob's talk at Agile 2008 after returning to Obtiva's Software Studio after a few weeks away.  One of the things he talked about was valuing "Craftsmanship over Crap".  After I spoke briefly with him afterward, it didn't seem like there was much more to his statement than simply promoting craftsmanship.  And that's fine by me, but I tend to be someone who picks up ideas like this and play with them for a while.  In my last post, I reworked "Craftsmanship over Crap" into "Craftsmanship over Heroics", and I'd like to say a bit more about why I chose heroics.  But first, I'll need to rewind the clock a bit.

In 2002, I read Pete McBreen's Software Craftsmanship.  I read a ton of great books that year.  Pete's book ranked near the top because of the ideals and structure that it described.  Similar to Kent Beck's Extreme Programming Explained, as I was reading the book I kept telling myself "this is how I want to work".  One of the themes of Pete's book is that "Software craftsmanship is built on top of long-term relationships that are grounded in a reputation for delivery."  One of the most satisfying aspects of pioneering Obtiva's Software Studio has been building the foundations of long-term relationships with our customers.  It's incredible how much ceremony and waste can be thrown out the window once a customer and development team can trust each other.  Watching some of Pete's ideals unfold in front of my eyes has solidified these ideals into hard won experience.

Unfortunately, like most developers who find a technique and use it successfully, it can be overused.  And by this I mean, letting all process fall away and simply execute your customer's every whim at maximum speed.  For me, this inevitably devolves into heroic programming.  There are times when you need a bit of heroism on a project, but this shouldn't happen more than a few times a year.  I recently found myself in a feedback loop of doing heroic programming at 2AM (and injecting bugs in the process), seeing some benefits, receiving praise from customer, fixing bugs the following night at 2AM (and injecting bugs in the process), seeing some benefits, receiving praise from customer, and on and on.  This is why the term "heroic" came to mind so quickly for me when I heard Uncle Bob. I've seen first-hand how a relationship with a customer can be taken too far and produce crap.  The obvious superior alternative is to stay disciplined, to maintain a healthy relationship with your customer, protect your sleep habits so that you're at your best, and to uphold your standards of craftsmanship.

I had the pleasure of listening to "Uncle" Bob Martin last night at Agile 2008 while we were eating dinner.  Bob is hands down the most entertaining speaker I've ever heard at a conference, and I've had the pleasure of listening to him at several of the Agile conferences.  The beautiful part is that while he entertains, he always has an important message, and his message this year was right on the money.  Never one to shy away from big ideas, Bob proposed to add a 5th value to the Agile Manifesto: Craftsmanship over Crap.  It was great to hear Bob continue to beat the craftsmanship drum, and Bob's slant on craftsmanship is all about professionalism.  He drew a wonderful comparison to the history of medicine when some hospital administrator discovered that having his doctors wash their hands lowered the hospital's mortality rate.  The critical tie-in for me was Bob's final words that "doctors don't have time to wash their hands," drawing a parallel with how often developers rush through our work without writing tests and keeping our code clean.

The problem with Bob's proposal is that it doesn't quite fit with the other agile values. There is no value in the item on the right!  I suggest we reword it to "Craftsmanship over Heroics".  While there are times that we need to be heroic for our customers, making a habit of heroic coding ends up producing crap and burns people out.

I just returned from a visit to my parents with my family.  My siblings and I are in kid-mode right now, with 7 cousins between ages 1 and 9, so we had some DVDs playing periodically as the cousins wore each other out.  One of the movies was Ratatouille.  The theme of that movie is near and dear to my heart because it shares the same grassroots, bootstrapping quality as the craftsmanship model and the way that apprentices are found and developed.  The movie is all about cooking and the theme is "Anyone can cook".

I believe that the Internet and Open Source have made this true for software developers.  Anyone with an Internet connection can learn some basic skills.  That's how I got my start, by reading an HTML tutorial online.  Just like most people have food and some tools for preparing it, many people have access to all the information they need to become a novice programmer.

A food critic at the end of the movie built on top of the "Anyone can cook" theme with "Not everyone can become a great artist, but a great artist can come from anywhere."  This quote hit home, particularly after giving my OSCON talk last week, which was fairly heavy-handed about Obtiva's success with people lacking a computer science education.

In one of the final sessions at OSCON today, Brian Tatnall and I spoke about our experiences with apprenticeship at Obtiva's Software Studio.  The slides are available for viewing from 280 Slides.

I attended my local Ruby Brigade on Monday and listened to Chris Hicks talk about sneaking Ruby into a Fortune 500 company. It was an interesting talk and I was impressed by Chris's ability to learn Ruby (his first programming language) over the course of a few months, and then present his experiences to a bunch of experienced Rubyists.  Afterward, a bunch of us grabbed some beers at a local pub and I had the pleasure of talking to Paul Pagel of 8th Light about apprenticeship.  Paul recently started mentoring an apprentice, so we had a lot to talk about.

I've thought about our conversation ever since and the different approaches that Obtiva and 8th Light are taking with their apprenticeship programs.

Obtiva hires apprentices into our Software Studio where apprentices are somewhat insulated from our clients and therefore have a relatively safe environment for learning.  The apprentices aren't assigned to a specific mentor, it's the Software Studio team's responsibility to ensure that apprentices are making progress and getting enough mentoring.  Sometimes we've failed to ensure that this happens as we balance client needs and team growth and the correct ratio of apprentices to more senior developers.

8th Light hires apprentices and attaches that apprentice to a mentor.  The apprentice shadows that mentor every day.  The mentor is responsible for finding and hiring the apprentice.  It's a more traditional approach to apprenticeship, and I assume that it's done in the context of on-site consulting work rather than in a remote environment like Obtiva's Software Studio.

It occurred to me this morning that while there are some business reasons for our different approaches, there is also some biographical reasons: my apprenticeship was less traditional than Paul's.  When I first met Paul, he was an intern at Object Mentor, a company led by Bob Martin, a long-time proponent of software craftsmanship.  Paul went on to work for Object Mentor and then moved onto 8th Light.  I, on the other hand, had a much bumpier (and perhaps typical) journey through several different companies, none of which emphasized apprenticeship.  I had to create my own apprenticeship in less than ideal circumstances (which is really what this book is all about).  My hope for Obtiva's apprentices is that they find themselves in much more ideal circumstances: within a culture of learning, a place to be mentored, and a place to stretch your skills.  Yet Obtiva's approach is closer to my own apprenticeship experience than Paul's.  At Obtiva, the quality of one's apprenticeship is largely in the hands of the apprentice, who will hopefully apply the Apprenticeship Patterns to maximize their experience.  Perhaps that's true of apprentices at 8th Light as well, though with a more traditional apprenticeship it would be easier to put the responsibility on the mentor.

I'll be interested to watch both Obtiva's and 8th Light's apprenticeship programs evolve in the coming years.  I'd like to see Obtiva's program take some steps toward becoming more traditional.

Michael Hunger asked whether we were including non-authors in our Basecamp collaboration.  I say: "yes!"  Please comment on this thread and let me know if you are interested in collaborating via Basecamp.  We would be looking for some help with reviewing and possibly offering some of your own stories to support the patterns.

One of the lessons I'm learning as I read through The Art of Learning is the importance and power of a peaceful state, and how periodic relaxation helps with this. One of my most thoughtful co-workers is Renzo Borgatti, who introduced my team to the concept of the Pomodoro technique.  When Renzo introduced it, I wasn't open to it.  I believed I could power through the intensity of my days without any breaks.  But coming back from a week off while reading The Art of Learning, I have an inner peace that is incredibly helpful to the sort of conceptual work that software developers do.  Yesterday was a typically hectic day for me, with many clients and co-workers vying for my attention, followed by an evening full of the same sort of thing, watching the kids while working through a long to-do list (fix sink, email uncle, plan anniversary).  Throughout the day I could feel my inner peace being challenged and sapped.  I could see the opportunities to step back and take a 5 minute break, though I didn't take them.  But unlike 6 months ago, I'm now open to the practice of the Pomodoro, just as I'm also beginning to research Tai Chi.

As I rode my bike to the train this morning, I was in a peaceful state. (I actually left early enough that I didn't have to rush.)  And I was thinking about next steps for the Apprenticeship Patterns and ways I could shift or jiggle my approach in order to jump-start the process.  I needed to get back to Mary about next steps.  And then a simple thought occurred to me.  Just use Basecamp.  For simple, small-team projects, Basecamp is a fine tool. We've used it effectively in developing Mad Mimi, so why not use it to manage the project of writing a patterns book, along with organizing the slides for my upcoming OSCON talk on Apprenticeship and Open Source?  I believe a tool like this, combined with periodic recovery periods should help create the rhythm and sustainable peace that I need to wear my many hats effectively.

And as a meta-example, this blog post is the second in as many days. Hopefully a rhythm is developing in my time of public reflection as well.  Stay tuned.

I've officially declared myself "blocked" as a writer. Declaring this will hopefully help pull me out of writer's-block-denial-land and help me get back on the path to developing these patterns into a publishable form.  I should say that my editor, Mary O'Brien, has been patient, understanding, and supportive through this process, particularly when I've been slow to respond (or unresponsive) to her inquiries.

I just spent a week offline and on holiday with my wife and children. It was an important and well-timed retreat and an opportunity to reflect on why I'm out of flow. Just before I left, Kevin Taylor, my business partner, handed me The Art of Learning (by Josh Waitzkin) just after he finished reading it. It's full of deep insights on learning and performance. It's also full of compelling auto-biographical stories from the chess champion who was the subject of the book and subsequent movie "Searching for Bobby Fischer", who went on to become a Tai Chi Push Hands world champion. The book is all about mastery, but digs deeper into the mechanics of elite performance and what separates the good from the great from the elite.

Two thoughts keep coming back to me as I read the book.

First, Josh has a lot of time on his hands. To be fair, he has exactly the same amount of time that I do.  He has 24 hours per day, in fact he has less time than I do since I'm older than he is. But when I read about him spending several hours a day refining his forms and literally taking hours to move his arms six inches, I realize that his days have very different structure than mine. I am a husband and father of three who tries to spend quality time with his wife and children every day. I am a software developer, team leader, mentor, and business owner who has projects, customers, teammates, and apprentices who need my time and attention. When I was describing Josh to my wife, I told her to imagine my focus on excellence and multiply it by 10. Despite the demands on my time, I have always carved out time to learn about and improve upon what I am currently focused on. For a long time that was American football, and then it was family systems and narrative therapy, and now it is software craftsmanship. I've also taken diversions into the martial art of Kenpo and explored Texas Hold'em poker. Like Josh, I love to learn, and I agree that it's an art. I appreciate that Josh has been able to structure his life in such a way that he can throw himself so fully into the art of learning and then benefit his readers with what he has discovered. But we all must strike a balance in our lives, and when we sacrifice our responsibilities for the sake of learning and mastery, we have slid into obsession.  That said, if I was neither a husband nor father nor business owner, it would be unlikely that I would be as disciplined as Josh to focus so much of my time on learning.  It's too easy to say, "well, he's a genius" or "he only has to worry about himself", but in reality, there are thousands of Josh's out there who lack the discipline to do what he does.

A second thought keeps coming back to me as Josh touches on the importance of allowing your personality to express itself in your craft. For Josh, this meant he played best when he could create chaos on the chessboard and then thrive in that chaos, just as he did in his normal life. When I read this, it was immediately obvious that over the last few years there has been an aspect of my life that is not congruent with who I am.  This incongruence between the various aspects of my life has caused various problems for me. I'm obviously not going into detail about what the incongruence is, but I feel comfortable writing about the effects of it in my professional life. The effects are simple but powerful: I'm off my game and out of flow. When you wear a lot of hats (father, team leader, consultant, husband, etc.) being out of flow feels exponential, as mistakes in one arena spill over into another, and another, and cascade into a mountain of disappointment. These mistakes can be technical, such as rushing through a software feature and choosing not to write tests for your code, or these mistakes can be relational, such as ignoring a customer's needs and missing out on an opportunity to innovate. Recognizing this incongruence was the first step toward correcting it. It is too easy to focus on the symptoms and problems caused by the incongruence, rather than dig down to the root cause and solve the fundamental problem. For example, if an alcoholic wants to overcome their addiction, they generally can't just focus on drinking less alcohol, they need to address the underlying issues that drove them toward alcohol abuse. Likewise I am in the process of digging deep to address my incongruence and turn things around.

This blog will get back on topic shortly! Please forgive my digression into self-improvement and introspection but it's an important step for me to overcome this blockage.

Over the last month I got into the nasty habit of not blogging. One of the toughest aspects of writing on the topic of apprenticeship is how easy it is to get distracted.  When a software developer writes about reading and learning, it's tough not to find yourself doing more reading and learning than writing.  It's not fair that there is always some new conversation, meme, API, or technology to learn about!  This problem of mine is what I love about this field, but makes focused writing difficult.  The reason this book stalled in 2005 was due to Ajax and then Ruby on Rails.  I simply could not ignore the opportunity they presented.  I was writing about the importance of one's ability to learn new technologies and there were two revolutionary technologies staring me in the face.  And now I find myself fighting off an endless barrage of distractions (aka opportunities) that slow down my book writing and blogging.  Thankfully (for the writing) I haven't recognized anything revolutionary enough to stall me for more than a few weeks.

One of my latest distractions is the polyglot meme. One of the apprenticeship patterns is Your First Language, which is a fundamental (if not obvious) pattern that covers the ins, outs, do's and don'ts of that first deep dive.  Neal Ford is one of the instigators of the polyglot meme and recently had some words of wisdom for learning a new language:

Anytime you learn a new language, you have 2 battles: first, learn the syntax (which is the easiest part -- it's just details of how familiar concepts are expressed in the new syntax). The second battle is the more important one: how to become an idiomatic programmer in that language.

My first language was Perl and I fell in love with it.  I thought it was the only language I would ever use.  And then I learned Java and Ruby.  One made me feel smart and one made me feel good.  These days I'm focusing more and more on JavaScript and with the help and guidance of Fred Polgardy, I am fighting the second battle that Neal was referring to. It's fun to know several languages, it's very freeing.  I still have many more languages to explore (Lisp, Scala, Haskell, Erlang, Python) and that's one of the self-serving reasons that I started The Polyglot Programmers User Groups recently.  I was actually leading a Perl Mongers group near my home but I was having trouble finding Perl speakers, so my colleagues and I morphed it into Polyglot Programmers SIG of Uniforum Chicago.  And this week is the first meeting of our downtown group, the Polyglot Programmers of Chicago.

I would enjoy hearing about your experiences learning your first and subsequent languages.

I mentioned in my previous post that we were considering changing the title of this book.  We have landed on Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.  It was tough for me to let go of "Apprentice to Journeyman" because that very much describes the transition this book is focused on, but we believe this title is more distinctive and descriptive of the content.

We will soon be doing a new release of the content of this site and the new title will be reflected at that point.

PragDave posted a criticism of this book's title 9 days ago.  I'm not going to go into details, but I will say he took the post down a day later and posted a public aplogy two days after that.  I will also say that it was quite an ordeal for me and that Dave's apology was unexpected and actually unecessary at that point since we had basically resolved things privately (no small feat via email).  So it was an incredible blessing to read the apology, and freeing.  I generally don't have any problem with hearing feedback about the title of this book, but the tone of Dave's criticism and my reaction to it took the whole conversation off-topic and completely closed my mind to critiquing the title myself.

Once Dave apologized I felt free to reconsider the title.  I wish I could have had the wherewithall to objectively look at the title before the apology, but I had taken the whole thing very personally and I was very much in you-can-pry-this-title-from-my-cold-dead-hands mode.  Thankfully my co-author Adewale was more objective and has been ruminating and suggesting better alternatives.  At the same time, I received a supportive email from my faraway friend Alan Francis who prompted me to consider changing the title.  I also spent some time with my team in Obtiva's Craftsmanship Studio brainstorming a new title.  And so Mary, our editor, and Adewale and I are considering a title change.  More information will be coming shortly.  I will say for now that the main title is most likely going to remain unchanged.

Paul Graham's essays inspire me.  I suppose this is because I already agree with most of them and he's just showing me how to construct arguments for the ideas that I unknowingly held.  One of Paul's common themes is the "great hacker" which resonates strongly with me because I aspire to become one of those people (referred to in this book as "master craftsman").  The theme that has a stronger influence on me is Paul's take on wealth and risk.  Paul points to the special powers and leverage that programmers can wield to generate wealth under the right conditions.  His arguments on wealth and risk helped steer me toward a local, three-man consultancy rather than an enormous multi-national bank when I left ThoughtWorks in 2006.  Choosing Obtiva was one of the better decisions I have ever made.

Paul's most recent essay is not about wealth or great hackers, but the related topic of company size.  Again, it resonated with me because I generally despise working in large organizations.  As someone who loves to create things, the constraints and layers of most large companies kill my soul.  And even if the large(ish) company (thinking of ThoughtWorks) has a hacker-friendly culture, there is nothing so thrilling to me as working in a very small company, simultaneously creating a culture and software systems of my own design.  Paul's experiences running his startup incubator has shaped his ideas about how inexperienced yet talented programmers should start their careers.  He advises people to err on the side of joining or founding a small company rather than joining a Google or a Microsoft for a few years to "learn the ropes".  As long as you can pay your bills without going into debt, I think Paul is right on target.  For programmers, learning is our fundamental activity, and there is no better way to learn than in the context of a small group of people working together to create something.  Spending a few years at a Google or a Microsoft will certainly teach you a lot, but some of it will be non-technical and company-specific and therefore useless once you move on.  I agree with Paul that those years would generally be better spent in a small company or your own startup where you have the leverage and leanness to optimize your learning experience and help you reach the next level of software craftsmanship.