Preface

      He who knows not and knows not that he knows not, is a fool — shun him!
      He who knows not and knows that he knows not, is unlearned — teach him!
      He who knows and knows not that he knows, is asleep — awaken him!
      He who knows and knows that he knows, is enlightened — follow him!

Arab proverb quoted by Lady Isabel Burton (1831–1896) in The Life of Captain Sir Richard F. Burton

Goals

We have written this book in order to share solutions to the dilemmas that are often faced by inexperienced software developers. We’re not referring to technical dilemmas; you’re not going to find any Java design patterns or Ruby on Rails recipes in this book. Rather, the dilemmas that we focus on are more personal, concerning your motivation and morale. This book should help you through the tough decisions that you face as a newcomer to the field of professional software development.

Audience

This book is written for the person who has had a taste of software development and aspires to become a great software developer. You may be a web developer or a medical device programmer, or you may be building trading applications for a financial institution. Or perhaps you have just graduated from high school or college knowing that software is your future.

Although this book was written for newcomers, more experienced developers will benefit from its content as well. People with several years of experience may find themselves nodding their heads in recognition of dilemmas they’ve already faced, and may come away with new insights or at least a new vocabulary to describe the solutions they want to apply for themselves or suggest to their colleagues. Even people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management.

Process

The idea for this book was first hatched when Stickyminds.com asked Dave to write a column about Software Craftsmanship in early 2005. Since Dave considered himself an (experienced) apprentice at the time, the only topic he felt comfortable writing about was apprenticeship. This got him thinking about what he would want to write on the topic. Around that time, Dave read a blog post by software developer Chris Morris1 that quoted guitarist Pat Metheny, and the seed for the pattern language was planted with the concept of “being the worst.” The seed quickly grew from Dave’s blog2 to a private wiki that Dave used to organize the initial patterns. The initial patterns were extracted from Dave’s career up to that point (2000–2005).

Understanding that these so-called patterns could not really be called patterns unless they were actually common solutions to common problems, Dave began seeking feedback from colleagues in three forms. First, he began publishing the patterns publicly on his website, soliciting feedback with public comment forms. Second, he began interviewing (mostly via email) thought leaders in the field of software development and getting their opinions on the initial patterns. Third, and most important, Dave began interviewing less-experienced practitioners to test the patterns against their recent experiences. The stories told by the less-experienced practitioners also introduced Dave to new patterns that he hadn’t yet encountered, or hadn’t recognized in his own experiences. It was during these apprenticeship interviews that Dave interviewed Ade, and by mutual agreement, Ade joined the project as a coauthor.

We (Dave and Ade) interviewed people who live and work in places ranging from Australia to India to Sweden. The settings for our discussions were just as diverse, ranging from comments on LiveJournal to an interview in a beautiful bomb-damaged church in the heart of London’s financial district.

At the same time, people like Laurent Bossavit, Daragh Farrell, and Kraig Parkinson were brave enough to try out the material in a variety of coding dojos, workshops, and boot camps. They then passed on the feedback they received and we (Dave and Ade) tried our best to incorporate it into our notes.

Later in 2005, we ran a focus group on our patterns at the Pattern Languages of Programs workshop.3 At PLoP, we were able to present our work to seasoned pattern authors (also known as shepherds) who gave us feedback on the format of our patterns and tested their own experiences as programmers against our assertions.

Around the same time, Mary Treseler of O’Reilly Media contacted us about publishing the patterns and encouraged us to keep writing. She helped us out by doing some editing, and two years later we had an agreement to publish the book. During that time we have spoken with countless colleagues via email, in user groups and conference sessions, or just over lunch about the patterns, and we continue to solicit feedback from the community online at http://apprenticeship.oreilly.com.

The end result is in your hands. It is a work grounded in dozens of interviews with practitioners as well as extensive research into the existing literature on learning, the psychology of optimal performance, and anything we could find on the topic of mastery. As you read further, you will see us cite surgeons, choreographers, and philosophers as well as the usual software luminaries. We believe that there is a lot to be learned from studying high performers in all disciplines.

Organization

A pattern is a named description of a recurring solution to a problem in a given context. The description should give readers a deep enough understanding of the problem to either apply the stated solution to their own context or decide that a particular pattern is not appropriate to their situation.

This book is made up of a few large chapters, each filled with a set of related patterns. The names of the patterns are capitalized (e.g., Breakable Toys), and related patterns are frequently referenced. Each chapter weaves its patterns together and provides an introduction to its themes as well as a section wrapping them up. The book’s introduction sets the stage for the pattern language, and the conclusion takes a look at “the big picture” regarding skill, apprenticeship, and mastery in our profession.

Pattern Form

Our pattern form is unusual. If you’ve read other books of patterns, you will see that we’re trying something different here. Compared to most pattern languages, we have fewer sections and less discussion of the resolution of abstract forces and constraints. This form was chosen based on extensive feedback from reviewers and from our workshop at PLoP. Based on that feedback, we believe this simpler structure will make our pattern language more accessible for our target audience.

Our patterns all consist of a context, a problem, a solution, and then a set of one or more actions. The context sets the mood, and the problem statement identifies the problem being solved by the entirety of the pattern. The solution usually begins with a one-sentence resolution for the problem, and then dives into greater detail on the issues involved in applying the solution, along with the pattern’s relationships to other patterns and supporting stories and literature.

Toward the end of each pattern is an action section, which describes something concrete you can do immediately if you wish to experience the effect of the pattern. These actions serve as example implementations. They supply exercises you can jump into immediately, without having to worry about the applicability of a pattern to your current situation.

It is important to remember that any pattern is meant to contain a family of solutions to a family of problems within a given context. Patterns are meant to be open to modification to fit your circumstances rather than mechanically applied. So if a pattern doesn’t precisely fit your circumstances, or none of the items in the action section seem suitable, then try to extrapolate from the raw materials we provide to see if you can build something useful.

Most of our patterns end with a “See Also” section, pointing to the page numbers for related patterns. This should help steer you away from a linear reading of the book in favor of a meandering path that gives you a deeper appreciation of the relationships between the different patterns.

Usage

A pattern language gives each person who uses it the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences.

The Timeless Way of Building, p. 167

Our goal with this project was to create a language of patterns to help you define your own apprenticeship. We cannot possibly know the context of your situation, so be sure to consider the context and problem statements of each pattern to determine whether it applies to you. The patterns are interconnected, and can be used together to create a more powerful experience. For example, while Find Mentors is an excellent and time-tested pattern all by itself, combining it with Rubbing Elbows is far more powerful. On the other hand, Expose Your Ignorance is more dependent on supporting patterns such as Confront Your Ignorance and Retreat Into Competence, and requires a bit more subtlety to use successfully. As with all pattern languages, you should be careful not to overuse these patterns. Don’t look for excuses to use every single pattern, but instead pick and choose the most appropriate set for your situation.

You do not necessarily need to read through the patterns in this book from front to back. When Dave read Christopher Alexander’s book A Pattern Language, he started in the middle and followed the connections between the patterns, which made for a more interesting learning experience. You may want to simply scan the “context” and “problem” statements of each pattern to find the ones that are relevant to your current situation. Scanning all the patterns in this way should help install some triggers in your mind for future situations, when some of the patterns may suddenly become applicable.

This book was initially written in a wiki, and as such it was never really intended to be read in a linear fashion. The early patterns will make reference to the later patterns and vice versa. This will be challenging, and will require you to actively engage with the material. You can browse it like a website, allowing yourself to be distracted by interesting links and never really knowing if you have read everything. There is nothing wrong with this approach.

Of course, we also understand that some people prefer to read from start to finish. Therefore, we’ve made an effort in the earlier chapters to minimize forward references, where a pattern refers to another pattern that appears later in the book.

Some people might find that they need to go through the book twice: first, a quick skim to get everything into their heads, and then a second time to connect all the links. This approach is also fine. This book is not meant to be used as a reference, but is more like an artist’s source book—you can dip into it for inspiration from time to time. You might even invent some new approach to using this book that we haven’t thought of. Go ahead. This book is like everything else in the real world: the connections aren’t always obvious at first, and every time you come back, you find something new.

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Apprenticeship Patterns by David H. Hoover and Adewale Oshineye. Copyright 2010 David H. Hoover and Adewale Oshineye, 978-0-596-51838-7.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at .

Safari® Books Online

NOTE

Safari Books Online is an on-demand digital library that lets you easily search over 7,500 technology and creative reference books and videos to find the answers you need quickly.

With a subscription, you can read any page and watch any video from our library online. Read books on your cell phone and mobile devices. Access new titles before they are available for print, and get exclusive access to manuscripts in development and post feedback for the authors. Copy and paste code samples, organize your favorites, download chapters, bookmark key sections, create notes, print out pages, and benefit from tons of other time-saving features.

O’Reilly Media has uploaded this book to the Safari Books Online service. To have full digital access to this book and others on similar topics from O’Reilly and other publishers, sign up for free at http://my.safaribooksonline.com.

How to Contact Us

You can contact David at or visit his home page to see what he’s up to.

You can contact Ade at . His website points to his photos, writings, and open source code.

Please address comments and questions concerning this book to the publisher:

  • O’Reilly Media, Inc.
  • 1005 Gravenstein Highway North
  • Sebastopol, CA 95472
  • 800-998-9938 (in the United States or Canada)
  • 707-829-0515 (international or local)
  • 707 829-0104 (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:

To comment or ask technical questions about this book, send email to:

For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our website at:

Dave’s Acknowledgments

I need to start out by thanking the people who gave me my first opportunities to become a software developer. Irv Shapiro, CEO of Edventions, hired me in April of 2000 at the end of my interview with him. Later that year he introduced me to Steve Bunes, CTO of Edventions and CEO of Risetime Technologies, and both of them guided me through my first excited steps into Perl and programming. When Edventions died the death of many other dot-com startups in April 2001, Steve put in a good word for me at the American Medical Association, where I spent the next three years surviving the aftermath of the dot-bomb. I’ll repeat my toast to Irv on the night after he hired me: “Thank you, Irv, for taking a chance on a gentile like me.”

Two people at the AMA gave me my first opportunity to move beyond my first language. John Dynkowski saw some potential in me, and recruited me to work on some of the AMA’s first J2EE projects. He did this at no small political cost to himself, and he was a constant source of encouragement during the 18 months that I worked in his department. Doug Fedorchak, my immediate supervisor, gave me the autonomy to sell Extreme Programming to upper management and pilot the AMA’s first Extreme Programming project. Thank you, John and Doug, for allowing an inexperienced but enthusiastic programmer like me to try out my ideas and make some waves in your organization.

If I had to point to one person who has had the biggest impact on me and my journey, it would be Wyatt Sutherland. I met Wyatt in 2002 at ChAD, the Chicago Agile Developers group, back when he was the group’s leader. I approached Wyatt about being his “apprentice” and he agreed to meet with me periodically for lunches and breakfasts. He did this despite his incredibly busy schedule as a traveling Agile consultant, music director at a local university, and father of four. Thank you, Wyatt, for your guidance during those years. It was a priceless gift and gave me the confidence to leave the AMA and aspire to work at companies like Object Mentor and ThoughtWorks.

I also need to thank my former employer, ThoughtWorks, for giving me access to a large group of people interested in contributing to this book, in particular my coauthor Adewale Oshineye. Thank you to ThoughtWorks’ Chief Scientist, Martin Fowler, for spending some time with me and sharing your insights on the writing process. ThoughtWorks graciously paid for my travel when Obie Fernandez invited me to come speak about the Apprenticeship Patterns at Agile Atlanta in 2005. Thank you, Obie, for your friendship and encouragement during our project together in Auburn Hills, for the invitation to Agile Atlanta, and for letting me sleep at your place when I missed my flight home. :) Thank you to my friend Laurent Bossavit, who presented the patterns to XP France in 2005 and translated the transcript to English for me. Thank you to Daragh Farrell, for presenting the patterns at Geeknight Sydney in 2005 and sending me the video of the discussion. Thank you to Linda Rising, for inviting both me and Ade to PLoP 2005, where we received a bunch of important feedback and had our first (and so far only) opportunity to meet face-to-face (and another thanks to ThoughtWorks for flying Ade to Chicago from London to attend PLoP).

At the beginning of my research into these patterns, I reached out to a number of well-known people in the software development community. These people spent time with me on the phone, via email, or both, offering feedback and wisdom based on their decades of experience. I am grateful to Ken Auer, Jerry Weinberg, Norm Kerth, Ron Jeffries, Linda Rising, Dave Astels, and Pete McBreen for spending some of their precious time guiding me in my writing. At the same time, I (and later Ade) reached out to dozens of less-experienced people (like myself) to ask for their input on the patterns and to mine their stories for common themes.

Much thanks to Adam Williams, Chris McMahon, Daragh Farrell, Desi McAdam, Elizabeth Keogh, Emerson Clarke, Jake Scruggs, Kragen Sitaker, Ivan Moore, Joe Walnes, Jonathan Weiss, Kent Schnaith, Marten Gustafson, Matt Savage, Micah Martin, Michael Hale, Michelle Pace, Patrick Kua, Patrick Morrison, Ravi Mohan, Steven Baker, Steve Tooke, Tim Bacon, Paul Pagel, Enrique Comba Riepenhausen, Nuno Marques, Steve Smith, Daniel Sebban, Brian Brazil, Matthew Russell, Russ Miles, and Raph Cohn for corresponding with us and relating their ideas and stories for us to use.

In 2008 we launched http://apprenticeship.oreilly.com, where we posted the content of the patterns for feedback from the community. Thanks to everyone who contributed, including Julie Baumler, Bob Beany, Antony Marcano, Ken McNamara, Tom Novotny, Vikki Read, Michael Rolf, Joseph Taylor, and especially Michael Hunger, who was an active participant in the forums and provided us excellent feedback from his several manuscript reviews.

I also need to express my gratitude to the daily passengers of the Metra Union Pacific West Line train that runs from Chicago’s Loop to the western suburbs. The majority of this book was written in the library-like silence of this train. Thank you for keeping to yourselves and enjoying your own books while I was writing mine. See you tomorrow!

I joined Obtiva in 2006, when Kevin Taylor convinced me that I should become its fourth employee rather than a subcontractor. It was certainly good advice, and has paid off in countless ways. I need to thank Kevin for supporting my untested ideas, handing me part of the company, cleaning up my continual messes, and taking care of so many unglamorous yet vital aspects of the business. I am excited about what the future holds for our company. One of the untested ideas that Kevin allowed me to run with was launching Obtiva’s Software Studio and bringing on apprentices who we could nurture into senior developers. Since starting the Studio in April 2007 we have brought on six apprentices, and I need to express my sincere thankfulness to our first three apprentices, Brian Tatnall, Joseph Leddy, and Nate Jackson, who bore the brunt of my many shortcomings and inexperience. The trial and error that these guys endured has helped us gradually improve the apprenticeships of our most recent three apprentices, Colin Harris, Leah Welty-Rieger, and Turner King. Thanks to all six of you for your dedication, enthusiasm, and desire to learn and grow in often less-than-ideal circumstances.

Mary Treseler is the person responsible for encouraging us to publish this project. From the first time she read our initial patterns in 2005, she found that they resonated with her, despite the fact that she was not a programmer herself. Thank you, Mary, for hearing our intent despite our inexperience as writers, and for sticking with us patiently through the years.

I was blessed with growing up in a very stable family. Although we moved around a lot, my mom and dad were steadfast in their examples as parents, spouses, and Christians. Having them as role models has made my transition into adulthood, marriage, and parenthood relatively painless. Marcia Hoover and Rick Hoover were a constant source of encouragement for me as a writer, from a very early age. Thank you, Mom and Dad, for nurturing my writing instincts.

Although I didn’t start programming until I was 26, I didn’t waste any time starting a family: my daughter was born when I was 24, just a few months before finishing graduate school. While starting a family under those circumstances is incredibly challenging, one of the things that my children gave me as a father was a laser focus on my responsibilities. There hasn’t been a day since Rose’s birth in 1999 when I could afford to be unemployed, and that is incredibly motivating for someone starting a new career. As my children have grown from babies to elementary-age kids, I have been inspired by watching them overcome obstacles in their own learning processes. This has reminded me to continue my own lifelong learning and to pursue knowledge as tenaciously as they do. Rose, Ricky, and Charlie, thank you for loving me unconditionally and for putting up with your fourth sibling, Daddy’s laptop. You should be seeing a bit less of it in the future now that this book is finished.

Ade’s Acknowledgments

First of all I’d like to thank all the people that Dave thanked. Without them Dave wouldn’t be here and therefore neither would I.

I’d like to thank the Pragmatic Programmers (Andy and Dave) for the inspiration that introduced me to the C2 wiki and the Extreme Tuesday Club. Without those influences I wouldn’t have found Laurent Bossavit’s Bookshelved wiki, and I wouldn’t have known who Dave was when he joined ThoughtWorks.

Of course, I wouldn’t have been a consultant there if, at an XTC evening at the Old Bank of England, Paul Hammant hadn’t challenged me to justify my unwillingness to join ThoughtWorks. Thanks, Paul. Being at TW opened a lot of doors. For example, the sponsorship of ThoughtWorks’ erstwhile Innovation Director, Dave Farley, meant I could go to Allerton for the PLoP conference and meet Dave in person.

The people who gave up their time to be quizzed about the details of their careers for this book know who they are. I can’t name you all here, but you have my eternal gratitude. The same applies to our reviewers. Thank you for taking the time to show us how to make this a better book.

Ravi Mohan didn’t just share his experiences with us. He asked us hard questions about every aspect of the book and the concept of software craftsmanship. His willingness to do the background reading, to change his mind, and to keep asking for definitions kept us honest. Thanks, Ravi.

I’d also like to thank Robert Konigsberg and Eve Andersson for providing incredibly detailed feedback on early versions of the manuscript.

I’d like to thank Enrique Comba Riepenhausen for creating the initial OmniGraffle diagrams. Without his help, you would be looking at some fairly ugly autogenerated diagrams made using Graphviz.

Writing a book on apprenticeship would have been impossible without a mentor. Ivan Moore didn’t stop being my mentor just because we didn’t work together anymore. I’ll always be grateful for that, as well as the tea.

I’d also like to thank Mary Treseler for taking a chance on Dave and me despite all the missed deadlines. We owe you one.

Finally, I’d like to thank my parents. They bought me my first computers, and they realized that I should be a professional programmer many years before I did. If I’d listened to them when I was younger, my path would have been shorter and more straightforward.

Get Apprenticeship Patterns now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial