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.
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, 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.
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,” 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. 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.” This is an idea that the software community has tried to capture with patterns like Expert in Earshot. 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.
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.
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.
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.