CHAPTER ONE
Introduction
Apprenticeship makes a difference because it instills a lifelong passion to master the craft. It instills a passion for perpetual learning and, in the process, enables the apprentice to become a great developer.
Pete McBreen, Software Craftsmanship
This book is written for software apprentices—for people who have had a taste of developing software and want to take it further, but need some guidance. Whether you have a college degree from a prestigious computer science program or are entirely self-taught, you recognize that there are great developers out there, and you aspire to achieve the same mastery that they possess. This book is written entirely for you—not for your boss, not for your team leader, not for your professor. There are many other books we would recommend for people in those roles, but this book is for people at the beginning of the journey.
While writing this book, we were heavily influenced by the principles and ideals of software craftsmanship. Indeed, the title of the book reflects this. The concept of apprenticeship is based on the medieval craft model, where small teams of practitioners work together and inexperienced apprentices help the journeymen and master craftsmen do their work. One of our goals for this book is to inspire the people who love to create software to stay focused on their craft. The journey discussed here starts with “Hello world!”, but where does it end? Far too often billing alarm, it ends with a promotion to middle management. Too many talented people thoughtlessly take that promotion and find themselves just a few years later in jobs they don’t enjoy and yearning for retirement. But for those who have a knack for developing software and enjoy the learning process, software development is a career that can last a lifetime, and it can be a great ride.
But before that ride can begin, we’re going to tell you Dave’s story and provide some definitions. His story shows one way that apprenticeship patterns can be combined to create powerful forces in your personal growth as a software developer. On the other hand, the definitions are an attempt to gather in one place the set of ideas that underpin software craftsmanship, and to answer some common questions about these ideas.
What Is Software Craftsmanship?
The dictionary definitions for simple words like craft, craftsmanship, apprentice, journeyman, and master are insufficient for our needs in this book. They are often circular (with craft being defined in terms of the skill a craftsman possesses, a craftsman being defined as someone who exhibits craftsmanship, and craftsmanship being defined as the quality that binds together the craftsmen working in the craft tradition), seldom grounded in the history of the guild system in specific countries, and often generalized to describe anything that is skillfully constructed. In short, these definitions fail to exclude anything and so include everything. We need more than that.
Google lists 61,800 references to the phrase “software craftsmanship,”2 but few of those references offer usable definitions to someone looking for career guidance. Sadly, many of the articles are written by well-meaning programmers who have found that there is something useful hidden away in this tangle of related concepts, but are unable to meaningfully extract it.
Pete McBreen’s book Software Craftsmanship is an attempt to put together a manifesto for an alternative approach to software development, aimed at those who do not operate under the assumption that software development is an engineering discipline or a science. But even McBreen’s inspiring work is flawed. It does not distinguish between software craftsmanship as practiced today, and software craftsmanship as he would like it to be practiced. Nor does he make a clear enough distinction between his vision and medieval notions of crafts as highly skilled industries overseen by secretive guilds. He makes the mistake of defining software craftsmanship in opposition to software engineering, and asking his readers to choose between them. We think that a craft model can be defined in a positive way that doesn’t exclude those people who feel that there’s something valuable in the attempt to build a discipline of software engineering.
The model that we draw inspiration from was prevalent in medieval Europe until the start of the Industrial Revolution (The Craftsman, pp. 52–80). In that model, the guilds controlled the masters and the masters controlled those who worked and lived in their workshops. The masters owned the workshops and had absolute authority. Below them in this strict hierarchy were the journeymen. They were usually craftsmen who had yet to achieve their chef d’oeuvre élève or “high masterpiece” that would demonstrate they were sufficiently skilled to be considered masters.
The journeymen were nomadic, and were the only means by which new techniques could pass from city to city. As well as bringing in new techniques, journeymen would supervise the day-to-day activities of the apprentices. The apprentices would work for one master for several years until they graduated to the ranks of journeymen by proving they had absorbed the basic skills and values of their craft. A person who did not fit into the guild’s hierarchy could not legally practice his craft.
As you can imagine, this system was open to abuse and is impractical, if not illegal, in today’s world. We do not wish to repeat the mistakes that moved this model to the margins of modern society. Instead, we believe it is possible to reject the romantic fantasy of the craftsman’s workshop in favor of a modern craft studio where we are free to improve upon the past, not just imitate it.
One of the lessons we’ve learned from the Agile development movement is that just telling people to do things doesn’t create lasting or sustainable change. When the people you’ve advised encounter a situation that isn’t covered by the rules, they’re lost. However, if those same people have imbibed the values that underpin the rules, they can come up with new rules to fit any situation. Our goal here is not simply to hand people a rule book, but to give them the ability to create new practices for new contexts, which in turn drives the discipline of software development forward.
Our vision of software craftsmanship is partly a distillation of the values of the highly skilled individuals we’ve interviewed for this book, and partly an expression of the kind of community we would like to see emerge. The ideas in this book are a starting point for that vision. So when we use the phrase software craftsmanship we’re talking about a community of practice united and defined by overlapping values, including:
An attachment to Carol Dweck’s research, which calls for a “growth mindset.” This entails a belief that you can be better and everything can be improved if you’re prepared to work at it. In her words, “effort is what makes you smart or talented” (Mindset, p. 16), and failure is merely an incentive to try a different approach next time. It is the opposite of the belief that we’re all born with a given amount of talent, and that failure is an indication that you don’t have enough of it.
A need to always be adapting and changing based on the feedback you get from the world around you. Atul Gawande refers to this as a willingness to “recognize the inadequacies in what you do and to seek out solutions” (Better, p. 257).
A desire to be pragmatic rather than dogmatic. This involves a willingness to trade off theoretical purity or future perfection in favor of getting things done today.
A belief that it is better to share what we know than to create scarcity by hoarding it. This is often connected to an involvement in the Free and Open Source Software communities.
A willingness to experiment and be proven wrong. This means we try stuff. We fail. Then we use the lessons from that failure in the next experiment. As Virginia Postrel puts it: “not every experiment or idea is a good one, but only by trying new ideas do we discover genuine improvements. And there is always more to be done. Every improvement can be improved still further; every new idea makes still more new combinations possible” (Future Enemies, p. 59).
A dedication to what psychologists call an internal locus of control.3 This involves taking control of and responsibility for our destinies rather than just waiting for someone else to give us the answers.
A focus on individuals rather than groups. This is not a movement with leaders and followers. Instead, we are a group of people who want to improve our skills and have discovered that debate, dissent, and disagreement rather than blind deference to self-proclaimed authority are the way to get there. We believe that we are all on the same journey and that the change we seek is in ourselves, not the world. This is why this book doesn’t focus on how to fix your team, but rather on ways to improve your own skills.
A commitment to inclusiveness. We don’t reject enterprise software development, or computer science or software engineering (in fact, Ade has the word “engineer” in his current job title). Instead, we think that a useful system should be able to identify and absorb the best ideas from all elements of the software development community.
We are skill-centric rather than process-centric. For us, it is more important to be highly skilled than to be using the “right” process. This idea has consequences. Gawande asked, “Is medicine a craft or an industry? If medicine is a craft, then you focus on teaching obstetricians to acquire a set of artisanal skills.... You do research to find new techniques. You accept that things will not always work out in everyone’s hands” (Better, p. 192). This idea suggests that no process or tool is going to make everyone equally successful. Even though we can all improve, there will always be discrepancies in our skill levels.
A strong preference for what Etienne Wenger calls “situated learning.”4 This is an idea that the software community has tried to capture with patterns like Expert in Earshot.5 Its essence is that the best way to learn is to be in the same room with people who are trying to achieve some goal using the skills you wish to learn.
This value system gives rise to different roles with different responsibilities, as discussed in the following sections.
What Does It Mean to Be an Apprentice?
When discussing what it means to be an apprentice, Marten Gustafson, one of our interviewees, put it best when he said, “I guess it basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing. Apprenticeship is the state/process of evolving and looking for better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways.” We think there’s a lot of value in having this internal drive that is not dependent on anyone else to bestow solutions upon you, and that leads you to find constructive ways of dealing with problems. As Dweck writes, “It is not an internal quantity that is fed by easy successes and diminished by failures.... It is not something we give to people by telling them about their high intelligence. It is something we equip them to get for themselves—by teaching them to value learning over the appearance of smartness, to relish challenge and to use errors as routes to mastery” (Self-theories, p. 4).
While the ideal situation would have you in a small team of fellow apprentices, journeymen, and a master, our understanding of apprenticeship does not require this arrangement. Your apprenticeship is under your control, and ultimately the outcome of your apprenticeship is your responsibility. While the course and progress of your apprenticeship are determined by you, the availability and quality of your mentors will also have a lasting impact on your craftsmanship.
Apprenticeship is the beginning of your journey as a software craftsman. During this time you will be primarily focused inward, intent on growing your craftsmanship. While you will benefit from the attention of your peers and more experienced developers, you must learn to grow yourself, to learn how you learn. This focus on yourself and your need to grow is the essence of what it means to be an apprentice.
An apprentice will eventually graduate from a position of few responsibilities beyond continuous learning to a position with wider and more outward-looking responsibilities, and we tend to believe that this transition is something that can only be seen in retrospect. At some point, an apprentice is approached by a master or a journeyman and told that her work and her role in the community are that of a journeyman. In such a case, the apprentice had previously begun taking on more responsibilities, and like a “boiled frog” had made a gradual but not discrete transition from one state to another. That transition may take longer for some people than for others. For some, the transition may take longer than their professional careers.
What Does It Mean to Be a Journeyman?
As you progress through the stages of craftsmanship, you retain the attributes of the previous stages. Therefore, like the apprentice, the journeyman and the master will maintain an inward focus in order to learn and grow in their craft. And yet, another focus is added for the journeyman. This new focus is on the connections between practitioners, the communication channels within and outside the team. Traditionally, a journeyman would move from master to master, along the way disseminating ideas between the various teams. The reality of modern software development is that you may be with a single team for a significantly long time; in this situation, you would focus on improving the connections within the one team. This focus will eventually expand into a responsibility to mentor those around you and to communicate with the rest of the industry.
The journeyman is focused on building an ever-larger portfolio of applications that demonstrates his progress in the craft; he moves between projects and masters, seeking to diversify and deepen his portfolio; he seeks to elevate his status within the community; and he strives to become ready to be a master.
The journeyman’s responsibilities are wider than those of an apprentice. As such his failures can do more harm. Some of the patterns we will discuss are not appropriate for a journeyman, precisely because he has a greater responsibility to others who may see him as a mentor.
What Does It Mean to Be a Master?
Mastery involves performing all the roles of an apprentice or a journeyman as well as focusing on moving the industry forward. The “acquisition of consummate skill and technique” (The Creative Habit, p. 167) is just the start. Mastery involves taking that skill and turning it into a magnifying glass that can enhance the skills of others by orders of magnitude. This may take the form of creating new tools that cut through to the essence of software development, or it may involve training a generation of journeymen whose skills equal and then surpass your own. Or it may take the shape of something that we can’t yet imagine. In short, masters view the acquisition, usage, and sharing of superior skill as the most important part of being a software craftsman.
The definitions of apprentice, journeyman, and master discussed here are not the kind you would find in any dictionary. This is something new. But we believe that the values inherent in our vision of software craftsmanship will help you to be as successful as you desire, whether you ultimately embrace them, enhance them, reject them, or follow a different road entirely.
What Is Apprenticeship?
The clichéd image of apprenticeship popularized by many books, including the 1945 edition of Fifteen Craftsmen On Their Crafts (p. 69) is that of a teenage boy with soot all over his face, working in a blacksmith’s shop. The blacksmith, a gruff, experienced craftsman, forges his projects with the boy’s assistance. Sometimes the boy is actively participating in the process; sometimes he is cleaning up the shop, yet still keeping a watchful eye on the master at work. Stereotypically, the boy’s apprenticeship would last a few years, and other than knowledge, experience, food, and lodging, the boy would receive little else in the way of payment. Eventually, the boy would acquire enough skill to take on projects of his own, perhaps even leaving his first master to take on a role with more responsibility in a different shop. When the boy’s apprenticeship was over, he could earn a living as a blacksmith, relying on his skills to provide shelter and food and tools for himself. In the modern world, an apprenticeship involving an accomplished software developer and a newcomer likely bears little resemblance to this stereotypical apprenticeship. So what’s our current understanding of apprenticeship, and how does it transcend the cliché?
To be clear, in this book we are not attempting to describe our proposed ideal apprenticeship for a newcomer to software development. If we were writing for team leaders and project managers, then providing instructions to build the ideal apprenticeship would make sense, because these people actually have the power to facilitate that sort of experience. But this book is for newcomers to software development, the people in the trenches trying to figure out how to learn what they need to know in order to accomplish objectives such as getting a (better) job, completing their project, or becoming a great developer. Since most newcomers’ experiences do not resemble the “ideal” apprenticeship, the modern concept of apprenticeship is mainly a frame of mind: you recognize that you are still at the beginning, even if you’ve been programming for several years, and you are prepared to take steps to create your apprenticeship out of the circumstances you are in.
Most people won’t have an opportunity to work in a formal apprenticeship where they are being mentored by software craftsmen. In reality, most people have to claw and scratch their apprenticeships out of less-than-ideal situations. They might be facing overbearing and/or incompetent managers, de-motivated coworkers, impossible deadlines, and work environments that treat novice developers like workhorses, storing them in small, rectangular stalls with a PC and a crippled Internet connection. All of the lessons of this book are taken from the experiences of people (like us) who had to overcome these sorts of circumstances in order to reach the next level. Until our industry can heed the following advice of Pete McBreen, newcomers will continue to need books like this to help them create their own opportunities for learning.
Apprenticeship is a way to learn about being a professional software developer. Specifically, it is a way to learn to be like the most skilled software developers you can find. It involves seeking out good teachers, and taking opportunities to learn by working alongside them. It is the first step on the road toward becoming a different kind of software professional—one who wants to be more than just competent.
What Is an Apprenticeship Pattern?
An apprenticeship pattern attempts to offer guidance to someone working with the craft model on the ways in which they can improve the progress of their career. All our patterns have been extracted from our own experiences and those of the people we have interviewed. Like any good collection of patterns, they should strike you as unoriginal precisely because the people around you are already using them. The other quality that these patterns share is that of generativity. Every time you apply them you should get different results, and if they’re used in the appropriate contexts they should improve your working environment. These are not algorithms that guarantee the same results on every execution. Instead they are tools that solve one set of problems and create new ones. The trick is to use your judgment to choose the problems you prefer.
This book is organized as a pattern language. A pattern language is an interconnected set of solutions to common problems in a specific domain. The original pattern language was written by Christopher Alexander in A Pattern Language, where he described over 250 patterns for designing everything from kitchens to houses to cities and even societies. Ward Cunningham and Kent Beck introduced pattern languages to the software industry in the 1990s, resulting in countless articles, books, and even conferences focused on design patterns. The best-known example of software design patterns literature is Design Patterns by “The Gang of Four” though Martin Fowler’s Refactoring is a better example of a pattern language. To be clear, the book you’re reading is not a book about designing software. Rather, it is a book about designing the beginning of your career in software development and setting yourself up to become great at what you do.
Where Did the Patterns Come From?
One of the principles of good software framework design is to extract the framework from a working system. Similarly, software design patterns are extracted from many working systems that have used the same solution to solve similar problems. This book was originally extracted from the stories of Dave’s apprenticeship experiences, then tested and supplemented with Ade’s stories, and finally tested against the experiences of about 30 practitioners with experience levels ranging from a couple of years to many decades. We interviewed these people in order to test whether these patterns were actually common solutions to common problems, along with mining for other patterns that we hadn’t recognized yet. We also participated in several workshops (PLoP 2005, Agile Atlanta meeting, and internal ThoughtWorks meetings) to help us focus on improving the structure and rigor of what we believed to be apprenticeship patterns. Finally, we have made much of this material freely available online in order to solicit feedback from the community.
Where Do We Go from Here?
As you begin learning about the patterns themselves, remember you have the power to choose them, combine them, and adapt them to your unique situation in an infinite number of ways. Understand that these patterns are written for a specific audience within a specific context. In the years ahead, some of the patterns will suddenly become relevant to you, and then just as suddenly some may feel inappropriate. An apprenticeship is a season in your career when your focus is more on your own growth than almost anything else. This is a time for you to delay your ambitions of immediately maximizing your earning potential in order to maximize your learning opportunities. Because of this, it is a season that affords a certain amount of selfishness. And once that season is over, your priorities will need to adapt. You will no longer be an apprentice, despite the fact that you still have much to learn, and your priorities will need to shift toward others: your customers, your colleagues, and your community.
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.
