Apprenticeship Patterns Interview with Dave Hoover and Adewale Oshineye

Dave Hoover and Adewale Oshieye are working on a book called Apprenticeship Patterns, which is due out in out in March of 2009. The book is about learning how to learn, and pushing yourself along the path toward a higher level of craftsmanship. While it's not Ruby-centric, I think it's the kind of book that will be widely read within Ruby circles. To get a jump on things, I've started an interview with Dave and Ade. Here's the first part:

---

Why don't you start out by telling us a bit about yourselves

DaveSure. So, I was a practicing child and family therapist until 2000 when I wanted to try my hand at programming. I learned Perl and was a Perl/CGI developer until 2002 when I "discovered" a bunch of different things like Jerry Weinberg, Extreme Programming, Ruby, and Java. Agile and Java were in their hayday so focusing on these helped me get a job at ThoughtWorks in 2004. My 2 years at ThoughtWorks was a great experience, it was during that time (2005) that Ade and I met (via email) and started writing the book. In 2006 I left ThoughtWorks to join smaller, more locally-focused consultancy, Obtiva. I'm now a principal of Obtiva, where I pioneered our Ruby competency, and founded our Software Studio practice.

AdeI started programming back in the 8-bit days using Basic and 6502 assembler. I then took a long detour into Political Theory and journalism until the late 1990s. I studied for an MSc and started working at a dotcom consultancy. In 2000 I stumbled upon Lightweight Methods (which is what the Agile movement used to call itself before the invention of the Agile brand) and through that the Pragmatic Programmer book. That one book introduced me to Ruby, Ward Cunningham's C2 wiki and the Extreme Tuesday Club.

At the time the Extreme Tuesday Club was Europe's epicenter for all things related to Agile, TDD and Mock Objects. We would meet up in a central London pub and people like Martin Fowler, Erich Gamma and Kent Beck would just drop by for a pint.

I eventually joined ThoughtWorks because back then they were recruiting all these really fantastic people and there was no way I was going to turn down the chance to work with people like Aslak, Nat Pryce, Obie, etc. The funny thing is that I think I'd already bumped into Dave on bookshelved.org by the time he joined ThoughtWorks. I have this vague memory of sending him an email in his first week at the company and saying something like "are you the Dave Hoover from bookshelved?"

Up until I joined Google I'd spent my entire career at various different kinds of consultancies across western Europe. I'm now a Technical Solutions Engineer which basically means that when it comes to the company's big strategic partners my group are responsible for everything from javascript problems right down to broken trans-Atlantic cables. The best part of the job is that I get to work with people across the entire company. As you can imagine this is a really good way to learn humility.

What are these apprenticeship patterns you're writing about, and why are they so important?

Dave These apprenticeship patterns were originally extracted from my experiences teaching myself how to become a software developer. I switched careers when I was 26 and taught myself Perl and JavaScript, and then Java and Ruby, and I've played with Scheme and Erlang. But the patterns aren't about any specific languages or technology, and they're not design patterns. These are behavioral patterns. For example, the first pattern I wrote was "Be the Worst", which was based on a quote from guitarist, Pat Metheny, who advised new musicians to try to always be the worst guy in their band.¹ This obviously doesn't mean to try to play poorly, it means to surround yourself with great musicians. When I read that quote in Chris Morris' weblog, it immediately resonated with me because it helped me describe why I had joined ThoughtWorks the previous year. I wanted to work with people who were better programmers than me, it's one of the best ways to learn.

I believe these patterns are important because they have a strong theme of staying technical, of being dedicated to one's craft, and pursuing the mastery of that craft. There are too many talented, yet short-sighted, developers who grab their first management opportunity and end up hating their job just a few years later. These patterns are important because we don't need a bunch more programmer-turned-manager people, we need a bunch more insanely experienced, talented software craftsmen that can wield their vast knowledge and experience to create innovative, robust software, and shape the next generation of software developers.

Ade These apprenticeship patterns are about capturing the common techniques that experienced people have used to build their careers and making them available to newcomers to the software industry. It turns out that a lot of the common techniques are grounded in certain values e.g. feedback is important, take responsibility for your career and fate, learn by working with people who know what they're doing on real projects, share what little you know in other to build a community, etc.

These patterns are important because they make it more likely that someone starting out today will be able to surpass their elders. If every software developer doesn't have to start their career from scratch and reinvent every technique that skilled people have been using for decades then it becomes reasonable to talk about the software industry moving forwards.

We're not claiming that this wisdom is ours. We've merely followed in the footsteps of books like the The Pragmatic Programmer and Software Craftsmanship. These are books that people keep telling us changed their lives. We're not quite that ambitious. But hopefully if we introduce new software developers to ideas like software craftsmanship and show them the most powerful ideas we know of then those people can use them to change their lives.

Dave,you mentioned the pattern "Be the Worst". One problem with "being the worst" is that there is always a senior member of any team. How do those people find ways to be the worst?

Dave Remember, these are apprenticeship patterns. They're for people who identify themselves as apprentices. So, if you don't identify yourself as an apprentice, then this pattern is not appropriate for you, instead you should be looking for opportunities to mentor more junior programmers. But if you do identify yourself as an apprentice, and you find yourself leading a team, and this is not uncommon for talented apprentices, then it's time to consider a couple apprenticeship patterns. First, "Use Your Title", meaning: if you've been programming for 2 years and your title is Senior Application Developer, then use that title to gauge your organization. Chances are your organization is sub-par if someone with so little experience could rise so quickly. Sure, you may be a natural, and you may be insanely smart, but if your learning is slowing and you're the best on your team, it's the right time to "Be the Worst", and look for a new team to join.

How does this compare to the more traditional kind of apprenticeship practised at Role Model Software?

Ade Sadly I've never experienced a proper apprenticeship or studio environment. The nearest I've got has been working with some of the stellar folks at ThoughtWorks. Dave's a much better person to handle this question. i will just mention that one of the goals of the book is to provide guidance for the vast majority of us who aren't lucky enough to get that kind of explicit mentoring.

Dave These patterns are different from the kind of apprenticeship that was (is?) practiced at RoleModel. That's because these patterns were extracted from the experiences of people who weren't in traditional apprenticeships. These patterns are going to be most useful for newcomers to software development who find themselves in less than ideal circumstances, the sort of circumstances that keep Dilbert in business. For example, one of the patterns is "Nurture Your Passion" and is written for the enthusiastic developer who finds himself in demoralizing situations at work and needs to the take the time to keep his passion for the craft alive. That pattern would be more relevant for an inexperienced developer working in a large, inept IT organization than an apprentice at RoleModel.

For those of us team leaders, project managers, and development directors who have the power to create more ideal circumstances for apprenticeship, Pete McBreen's Software Craftsmanship is a more relevant book. Reading about the ideal scenarios in Pete's book inspired me to scrape my own informal apprenticeship together out of non-ideal circumstances. And then I used Pete's ideas, combined with my own, to create an apprenticeship program similar to RoleModel's in Obtiva's Software Studio.

How well are these patterns going to transfer to the technical non-programmer (say, a sys admin like me)?

Dave I would think they would transfer well to system administrators, database administrators and web designers. I know that my editor at O'Reilly, who is non-technical, found some of the patterns useful in her own career. The patterns are mainly about learning, attitude and motivation, so the details that are specific to programmers shouldn't be too much of a hindrance.

Ade I think you will find that these patterns are very useful to someone in your position. A lot of the ideas in the book are drawn from a wide range of sources and expressed through patterns. For instance we cite Twyla Tharp ( a dancer turned choreographer) and Atul Gawande (a surgeon) qute often because they're highly skilled practitioners of their disciplines who have written about the path they took.

I would probably quibble with your description of yourself. You're more than your job title. The best sys-admins I've ever known were people who spent time reflecting deeply to find trends in the problems they were fixing, created feedback loops, dug deep below the surface of issues/systems and did many other things that could have been taken straight from our book. I suspect that technical people in the software industry have far more in common with each other than our arbitrary job titles would lead us to believe.

You will probably find our perspective (as developers) a bit different to your perspective. However you should find that the patterns are useful to you precisely because they talk about things you're already doing or planning to do. The example implementations of the patterns, which we've called Action sections, might not be as relevant to you though.

In fact we tackle this issue in the preface. The preface points out that patterns are meant to be a mapping from a family of problems to a family of solutions. The way you apply this mapping will depend on your current context. Even though we assume that the majority of our readers will be full-time software developers the fact that you're a sys admin or a DBA is just a slight modification of this context. I look forward to seeing how that affects the solutions generated by your usage of the patterns.

Ade, I liked your reminder that developers and sys-admins/DBAs have more in common than we often think. It reminded me of a blog post by Andrew Shafer. How do you think we can best build on that commonality?

AdeI found that blog post about the tribal nature of the software industry to be very insightful. Unfortunately we tend to have teams who don't maintain the systems they build and who feel that production support is somebody else's job. As the systems we all build/maintain/administer/support start to handle ever more data, need to scale better and users develop expectations based on the consumer-facing web-apps they use we're not going to have the luxury of that kind of horizontal specialisation. We're all going to need to develop a more thorough sense of the stack on which we're building rather than just throwing code over a wall.

The way we can build on this commonality is by arranging conferences that span the tribes so that we can start to realise how much value other people's skills have. Those of us who don't arrange conferences can do our bit to help by trying to go to at least one conference a year which is filled with people who have an 'alien' but effective perspective. Find a community of web designers, embedded sensor network programmers, unix sys admins, kernel hackers, etc and just lurk at one of their conferences.

Soaking up the ideas that other groups of highly skilled people care about can bridge the divide but it can also give you valuable new insights into your own work. For instance I use the techniques in Tom Limoncelli's book Time Management for System Administrators to help me manage my day. It really helped me when systems like GTD didn't seem to fit the way I live or work.

Andy Hunt's new Pragmatic Thinking & Learning book talks a lot about the Dreyfuss model and learning to push your way up it. Where does self-imposed apprenticeship fit in that process?

Dave I still need to read all the way through Andy's book. I had to put it off so I could finish mine, but I've heard rave reviews about it. I honestly don't know anything about the Dreyfuss model, so I'll have to defer to Ade on this one.

Ade I haven't read Andy's book but it's on my reading list but I've read the presentations that both Andy and Dave Thomas have given about the Dreyfus Skills Acquisition model. I think both books complement each other.

We had a candidate pattern called Learn How You Learn which isn't likely to make it into the book since only a few of our interviewees had used it. This pattern was about finding out which techniques for learning were the most effective for you and then trying to make sure you prioritised their usage accordingly. The idea being that if you're aware of the set of potential learning styles then you can detect situations where you're using an inappropriate style and fix it. However the people who had tried this seemed to see it mostly as choosing to learn from reading books or by trying to build things.

Compared to Andy's our work tends to focus more on the factors that propel someone through the different levels of the Dreyfus model using a system of values. In effect we're trying to place learning in a wider social context. Even though I'm a big fan of the Dreyfus model I think that that the shuhari model has some advantages over it for the kind of people we hope will read our book.

The Shuhari model (first you obey rules, then you try to break the rules, then you just do whatever makes sense in context) claims that each level still retains the qualities of the earlier levels. These are not so much steps on a ladder as concentric rings. This is important to software craftsmanship because of the tension between tacit knowledge (where somebody just knows the right thing to do in a given context) and the transmission of skill. If you're wandering around just doing whatever makes sense and you're getting great results then I'm happy for you. However in the craftsmanship model you need to actually pass your skills on. You have to break out of your unconscious competence by creating new rules or heuristics so that new apprentices can match and eventually surpass your achievements. If we don't do this we run the risk of falling into the same trap as people like Stradivari where the quality of their workshop's output declined after they died. As software craftsmen we have a duty to help to create teams that can sustain and even improve their skill level when we leave.

The only way this can work is if you retain an awareness of all the places where you don't have unconscious competence and have to blindly follow rules. You may be the world's greatest C programmer but the memory of all the times you have to cling to the rules for normalising a database schema is what makes it possible for you to start thinking about representing your C skills in way that others can imitate and enhance.

Atul Gawande's book, Better, has a wonderful section where he talks about the importance of checklists for people who are highly skilled. The checklist is how they make sure that they don't leave instruments inside the patient when an operation develops complications or forget to wash their hands after seeing a patient who is terminally ill. His point is that tacit knowledge is easily forgotten by experts in moments of great stress but the checklists can be used by the less skilled members of a team to keep everybody honest. In fact some of my fondest memories of ThoughtWorks projects are the moments when someone I've taught TDD asks "is there a test for that?" At that point I've either been caught as I'm about to cut a corner or I've been caught applying some meta-heuristic without explaining it first. Either way everybody learns something.

The Dreyfus model seems to be focused on helping the teacher tailor lessons based on their assessment of the level of their students. I agree about the importance of "directed skill acquisition" and that working with someone who knows what they're doing is definitely the best way to learn. However most apprentices won't have a teacher or mentor because there are surprisingly few people in the industry who want to provide guidance to others. You have to consciously set out to find these mentors who can guide you up the levels of whichever model you wish to use.

---

1 Chad Fowler read the same quote in the same blog post and wrote about the same concept in My Job Went to India.