apprenticeship-patterns.md

Apprenticeship Patterns (2009)

Adewale Oshineye & Dave Hoover

───────────────

▪ Twenty-five years ago Kent Beck and I sat in Tektronix’s Technical Center cafeteria wondering what impact our privileged access to Smalltalk-80 would have on the world.

Never mind reality, I advised Kent. If we could do anything, what would we do with this knowledge?

“I want to change the way people think about programming,” Kent said. I agreed. We both wanted to reverse what we thought had been a wrong turn in the progress of our industry. And, amazingly, we did it.

▪ We say that patterns solve problems. “Never mind reality” solved a problem for Kent and me. It got us thinking big thoughts that stuck with us and let us push through our habitual self-censorship.

▪ The strongest patterns are the ones that are applied productively over and over again

▪ Just knowing the names for established patterns is a big help too.

▪ Identifying a pattern lets you discuss it without having to retell the whole story every time.

▪ Many will be familiar. For any one you might say, “I already have that pattern”—and you probably do. But there are two ways that the written patterns here can help you, even when the solution is common knowledge.

First, the written pattern is more complete. It has been studied, characterized, classified, and explained. You’ll find unexpected nuggets in each pattern. Savor these nuggets. They make the patterns you already have more powerful

▪ The piecemeal growth of pattern terminology became a foundation for Agile software development methods. Many more dozens of books have subsequently appeared

▪ Well, we’ve overloaded our profession with resources. There is more information available about our revolution than any one person can absorb. Still, some people manage to do it. They internalize all the advice available to them and always seem to have it close at hand. How do they do achieve that level of mastery?

▪ Mastering is more than just knowing. It is knowing in a way that lightens your load.

▪ Let me give you an example. If you can’t remember the order of arguments to the SUBSTR function, you can look that up on the Internet. Thank goodness for the Internet. It has lightened our load a little. But when you use this book’s patterns, when you approach your work always open to improvement, you will find yourself writing a different kind of code, code that doesn’t depend on knowing the order of SUBSTR’s arguments. You will write programs that soar far beyond SUBSTR. This will lighten your load a lot

▪ All the advice that has come out of our revolution does not help much until it becomes second nature

▪ The craftsmanship movement in software recognizes that making this stuff second nature isn’t, well, second nature

▪ These patterns are a welcome contribution to this progression

▪ 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

▪ 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

▪ 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 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.

▪ 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.

▪ 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.

▪ 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

▪ 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

▪ 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.

▪ In March 2009, after prolonged discussion on the software_craftsmanship mailing list, the following manifesto was drafted

▪ As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

  Not only working software, but also well-crafted software
  Not only responding to change, but also steadily adding value
  Not only individuals and interactions, but also a community of professionals
  Not only customer collaboration, but also productive partnerships
  That is, in pursuit of the items on the left, we have found the items on the right to be indispensable.

▪ 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

▪ 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.

▪ I discovered that Joshua Kerievsky was working on Refactoring to Patterns which sounded impressive, so I found a kindred spirit to study it with me

▪ The dictionary definitions for simple words like craft, craftsmanship, apprentice, journeyman, and master are insufficient for our needs in this book.

▪ 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

▪ Nor does he make a clear enough distinction between his vision and medieval notions of crafts as highly skilled industries overseen by secretive guilds.

▪ 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 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

▪ 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.

▪ 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.[6] 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

▪ 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.”[7] 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

▪ 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).

▪ 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.

▪ 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.

▪ 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.

▪ Mastery involves performing all the roles of an apprentice or a journeyman as well as focusing on moving the industry forward

▪ 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.

▪ The fundamental learning situation is one in which a person learns by helping someone who really knows what he is doing.

—Christopher Alexander et al., A Pattern Language, p. 413

▪ 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.

▪ We can take the time needed to nurture apprentice developers because we are faced with the problem of abundance, rather than scarcity....Today we have more developers than needed, but we have a shortage of good developers.

—Pete McBreen, Software Craftsmanship, p. 93

▪ 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

▪ 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

▪ 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.

▪ 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

▪ 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.

▪ One of the fundamental ways to improve the experience of learning your first language is to have an actual problem to solve. This helps to ground your learning in reality and provides you with your first, relatively large, feedback loop. Learning with the small, contrived examples in books and articles is limiting, and you lose the benefit of applying your discoveries to a problem you have in your head, which, after all, is what you’d be doing on the job.

▪ The fundamental way to improve this experience is to seek out opportunities to create feedback loops. In particular, creating short feedback loops helps you gauge your progress. Some languages have better tools for feedback than others, but regardless of the language, you can take some steps to set up a learning sandbox to experiment in.

▪ Eric Merritt’s blog post “The Shape of Your Mind” dives into how programming languages can have a profound impact on your problem-solving skills:

▪ As a rule, each step should have a feeling of entrance. This is beginner’s mind—the state of becoming.

—Shunryu Suzuki, Zen Mind, Beginner’s Mind

▪ You are struggling to learn new things and it seems somehow harder than it was before to acquire new skills. The pace of your self-education seems to be slowing down despite your best efforts. You fear that your personal development may have stalled.

▪ Find an opportunity to unlearn something. Ideally, this would be something that forces you to put aside your previous experience.

For instance, take a program you have written in one programming paradigm (e.g., imperative, object-oriented, functional, array/vector-oriented, etc.) and implement it in a language that uses a different paradigm. Make sure your new implementation follows the idioms of the new language. If all the languages you know use the same paradigm (e.g., object orientation), then this is also an opportunity to learn a new paradigm.

▪ Apprentices are an essential part of software craftsmanship because they bring an enthusiasm and drive for learning that infect everyone else.

—Pete McBreen, Software Craftmanship

▪ Do not allow anyone to dampen your excitement for the craft—it is a precious commodity and will accelerate your learning

▪ In James Surowiecki’s The Wisdom of Crowds, he repeatedly points to diversity of thought as a key ingredient of collective intelligence.

▪ An intriguing study on the collective mind of aircraft carrier crews showed that newcomers played an important role in the complex, coordinated group activities required to safely operate an enormous boat with fighter jets constantly coming and going. The researchers found that it is actually healthier for a team to consist of people with varying levels of experience

▪ Craftsmen learn from the apprentices, even as the apprentices learn from them. Enthusiastic beginners not only renew the craftsmen, but also challenge the craftsmen by bringing in new ideas from the outside. A well chosen apprentice can make even a master craftsman more productive.

—Pete McBreen, Software Craftsmanship, p. 75

▪ Concrete Skills

Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in.

—Pete McBreen, Software Craftsmanship

▪ As you begin to make the transition to the role of journeyman you will become less dependent on these skills, as you start to be hired on the basis of your reputation, your portfolio of previous work, and the deeper qualities you bring to a team. Until then, your virtues must be a little more overt.

▪ As I progressed as a programmer, I would meet people who would get very excited about my past, and this led me to occasionally overvalue these softer skills, or overpursue nontechnical topics. To be sure, my soft skills have served me well and have helped me tremendously in many situations; however, I have had to let these skills atrophy a bit in order to focus the majority of my attention on developing my technical skills, which was obviously the area where I was most lacking. I didn’t switch careers so I could be a therapist to programmers; I switched careers because I love the act of crafting software.

▪ Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.

—Jake Scruggs in “My Apprenticeship at Object Mentor”

▪ The people who are paying you to be a software developer are depending on you to know what you’re doing.

▪ According to research by the social psychologist Carol Dweck, the need to appear competent is ingrained into people of most industrialized societies. These societies are increasingly dependent on your competence as a developer, as software creeps ever-deeper into our everyday lives. Yet because of your inexperience, you have many zones of ignorance. You are in a bind. The people around you—your manager, your client, your colleagues, not to mention yourself—are all under tremendous pressure to deliver software. You can see the need for confidence in people’s eyes when they ask you how long feature X will take you to finish. There can be tremendous pressure to pacify them, to reassure them that you know precisely what they want, how you’re going to give it to them, and when.

▪ Software craftsmen build their reputations through strong relationships with their clients and colleagues. Conceding to unspoken pressures and telling people what they want to hear is not a good way to build strong relationships. Tell people the truth. Let them know that you’re starting to understand what they want and you’re in the process of learning how to give it to them. If you reassure them, reassure them with your ability to learn, not by pretending to know something you don’t.

▪ In this way, your reputation will be built upon your learning ability rather than what you already know.

▪ The most obvious way to expose your ignorance is to ask questions. This is easier said than done, particularly when the person you’re asking has assumed that you already know the answer. Press on! Sure, you could protect your pride and take less direct routes to obtain the required knowledge, but remember that your road to journeyman will be shortened by taking the most direct route available.

▪ With practice and time, you will find that asking direct questions to the most knowledgeable people on your team will become second nature.

▪ Your instincts tell you to hide your ignorance, to feign expert knowledge, but this only stunts your growth and inhibits the work you are trying to accomplish. Taking this lesson with me from one career to another has served me well. I actually had grown attached to feeling ignorant on a daily basis; it let me know I was in the right place. I was growing.

▪ Write down a list of five things you really don’t understand about your work. Put that list where others can see it. Then get in the habit of refreshing this list as your work changes.

▪ There aren’t enough hours in the day to hone all your skills to a high level, so you must learn to make the necessary trade-offs between them.

▪ However, as an apprentice with aspirations to mastery, you need to be willing to Expose Your Ignorance as well. Using this pattern in isolation (that is, confronting your ignorance without exposing it) runs the risk of encouraging a culture where failure and learning are unacceptable because everybody does their learning in secret.

▪ Remember that learning in public is one of the ways in which an apprentice begins the transition to journeyman. It’s a small step from learning where people can see you to teaching.

▪ In short, you need to be sensitive enough not to let your apprenticeship become a problem for the team. One of the distinguishing facets of the craft approach is a willingness to put the wider interests of your community before your own, rather than using the team and the client to further your personal growth.

▪ Even though we advocate seeking out the most challenging tasks you are capable of, you still need to remember that if the water level is above your head it means you’re drowning.

▪ It’s also your responsibility to Create Feedback Loops, so that if the challenging project starts to spin out of control you can catch it and get help immediately. Applying this pattern should feel brave rather than reckless.

▪ You look at where you’re going and where you are and it never makes sense, but then you look back at where you’ve been and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something.

—Robert Pirsig, Zen and the Art of Motorcycle Maintenance

▪ An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues. Take heart. This is a normal and inevitable phenomenon along The Long Road. Overcoming the fear of your own incompetence is the bridge between Expose Your Ignorance and Confront Your Ignorance.

▪ All this talk of ignorance, deep ends, exposure, and retreat might sound negative. But ignorance is not a bad thing if it is recognized and confronted. The worst case is that you’re not even aware of your ignorance, but if you recognize what you’re missing and address it, you’ve taken a step forward. One of the foundations of a solid apprenticeship is an Accurate Self-Assessment, in which you try to determine how far along the path you are and take note of any gaps in your knowledge.

▪ You need to become intimately familiar with your competencies, the skills you need to immediately become competent in, and the knowledge that interests you long-term.

▪ “How long will it take to master aikido?” a prospective student asks. “How long do you expect to live?” is the only respectable response.

—George Leonard, Mastery

▪ For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.

—George Leonard, Mastery

▪ During your apprenticeship, value learning and long-term growth opportunities over salary and traditional notions of leadership

▪ If you’re still going to be working in 20 years’ time, then you can do anything. No one is so far ahead that you can’t match their skill level given the decades you will have to hone your craft

▪ The Long Road is the foundation. The transition from apprentice to journeyman is only the first of many steps along the path to mastery.

▪ Ours is a complex and profound path, a path that by its nature changes continually. Moore’s Law marches relentlessly on, regularly opening up new opportunities for craftsmen to explore new platforms or reprioritize the characteristics of an established program. And yet, other changes are often superficial. New technologies replace older technologies, yet solve the same fundamental problems. While there will always be new software to learn and better hardware just around the corner, The Long Road teaches craftsmen the deeper truths of the craft, allowing the masters to transcend specific technologies and cut to the heart of the problem.

▪ You are being paid to build something that will solve a problem for a customer.

▪ As a craftsman you are primarily building something that serves the needs of others, not indulging in artistic expression. After all, there’s no such thing as a starving craftsman. As our friend Laurent Bossavit put it: “For a craftsman to starve is a failure; he’s supposed to earn a living at his craft.”

▪ You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community.

▪ If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.

▪ The things we build for customers can be beautiful, but must be useful

▪ Part of the process of maturation encompassed by this pattern is developing the ability to sacrifice beauty in favor of utility if and when it becomes necessary.

▪ Indulging in the creation of beautiful but useless artifacts is not craftsmanship

▪ Another aspect of craft over art is that your customers need you to produce satisfactory quality even when you don’t feel like it.

▪ Working on real problems for real people is what hones the craft, not just doing it for self-satisfaction.

—Ken Auer, email

▪ When using this pattern you will have to balance your customer’s desire for the immediate resolution of their problem with the internal standards that make you a craftsman. Being able to hold on to these standards even when you are under pressure requires you to develop an understanding that utility and beauty are not opposed, but interdependent.

▪ You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility. Sometimes you will make the wrong trade-off, and fixing that mistake by rewriting the system from scratch may not be in the customer’s best interest. In those situations you will need to develop the ability to refactor and repair.

▪ As Sennet wrote, “it is by fixing things that we often get to understand how they work.”

▪ In this case, the time spent on fixes when you have veered too far toward either art or expediency will teach you lessons about software development that cannot be learned in any other way.

▪ As an apprentice, you must develop your technical skills. Because of this you will often find yourself working in the messy realities of ambiguously specified projects for customers with shifting and conflicting demands.

▪ Working in the trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining.

▪ there is not much overlap between the kind of software that makes money and the kind of software that’s interesting to write.... If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.

—Paul Graham, Hackers & Painters

▪ Unfortunately, your daily activities often work to diminish this passion. You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it.

▪ Project death marches are probably the most damaging of the hostile conditions. It’s hard to imagine how you could protect your passion, let alone grow it, in the face of a death march. It saps your time and your energy, preventing you from taking any significant actions to protect your passion as more important issues like personal health and strained relations at home demand your attention. Death marches play into the hero mentality that is prevalent in many software development organizations. The people who walk The Long Road are not the heroes who sprint for a few years and burn out—they are the people moving at a sustainable pace for decades.

▪ To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This might mean you leave work while the rest of the team stays late, that you walk out of a meeting that has become abusive, that you steer a cynical conversation toward constructive topics, or that you refuse to distribute code that doesn’t meet your minimum standards. The result could be that you get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong.

▪ Any given employer can offer only a limited subset of all possible career paths

▪ Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.

▪ You should continuously reassess your map as your circumstances and values change. Sometimes your map will be in accord with that of those around you, and sometimes your map will require you to chart your own path through the wilderness. Some apprentices we’ve spoken to have found that being open about their current map has enabled them to find Kindred Spirits while maintaining healthy relationships with current and past employers.

▪ The only constant is that the map is always yours, and you’re free to redraw it at any time.

▪ Some organizations will be able to rally behind the audacious goals their people set for themselves. Other organizations choose not to. If this is the case at your organization, you need to begin to look elsewhere by Expanding Your Bandwidth and Finding Mentors who can provide guidance.

▪ I’m promoting you from Senior Engineer to Lead Engineer.

The pay is the same but people will disrespect you less.

—Dilbert’s Pointy-Haired Boss

▪ As a result of your dedication to learning, you have been hired or promoted (formally or informally) into a position with a title containing words such as “senior,” “architect,” or “lead.”

▪ Your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description.

▪ Do not allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness

▪ Use your title to gauge your organization, not yourself.

▪ Don’t be fooled by an impressive title. Your mother might think you deserve it, but impressive titles and responsibilities do not indicate that your apprenticeship is over

▪ The other side of the coin is an unimpressive title despite the fact that you have surpassed your colleagues. Like the flattery of an impressive title, the frustration that comes from a lack of recognition should remind you that our industry has a problem. Again, use this situation to measure your organization and its fit for you rather than allowing the frustration to slow you down

▪ If for some reason you could no longer be a software developer, what would you do? Write down some of the other jobs you think you would enjoy doing

▪ Find people who are doing those jobs and loving it. Ask them what they love about it and compare that to the things you love about software development

▪ Your goal is to measure your abilities and find ways to be better than you were yesterday. We’re all on the same journey, and comparing ourselves to others is useful only when it allows us to find ways to help each other improve.

▪ Be the lion’s tail rather than the fox’s head!

—Tractate Avot

▪ Be the Worst was the seminal pattern of this pattern language. It was lifted from some advice that Pat Metheny offered to young musicians: “Be the worst guy in every band you’re in.”[21] Pat’s advice struck a chord with Dave, and was one of the reasons he started writing this book.

▪ Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think

▪ It’s only when you work on your own that you will see how much your team increases your productivity and realize how much you have learned.

▪ Be the Worst clashes with cultural norms that encourage you to attain a position of superiority as fast as you can. But as an apprentice, you should value opportunities to learn the craft over expanding and asserting your authority. Sometimes that means you’re leading a team (see The Deep End), but as an apprentice, you should typically look to be led.

▪ Without a doubt the coolest thing about working at Object Mentor was being able to lean over and ask David, or Micah, or Paul, or James, or ... Look, everybody sitting next to me had great ideas about programming and, as cool as all their classes are, working with great programmers is a much better way to learn.

▪ Whether a beginner starts out with a training course or is self-taught, the first step on the path to software craftsmanship is finding a craftsman to apprentice himself to.

—Pete McBreen, Software Craftsmanship, p. 96

▪ Ideally, you will find a master craftsman who will accept you as an apprentice. You will remain under her supervision throughout your apprenticeship, establishing your future on the foundation of your master’s reputation. However, this ideal is exceptionally rare in today’s world.

▪ Furthermore, as an apprentice it can be difficult to tell who is truly a master craftsman. Therefore, it is more likely that your apprenticeship will be supervised by a series of mentors who possess varying degrees of mastery.

▪ Real-world apprentices have to scratch and claw their way into the lives of master craftsmen and are grateful for whatever attention they can get, particularly face-to-face or, better yet, side-by-side.

▪ Having said that, you may find that the most influential and helpful mentors for you are not physically available. They may live in a different country; they may even be long dead, as in the case of someone like Edgar Dijkstra. But that doesn’t mean that they can’t still act as beacons, lighting the way forward.

▪ If you should end up with a teacher who doesn’t seem right for you, first look inside. You might well be expecting more than any teacher can give.

—George Leonard, Mastery, p. 71

▪ It can be tempting to feel that your mentor must be a master because she knows so much more than you do. That temptation must be resisted, because you do not want to become so disillusioned with your mentor’s inevitable weaknesses or blind spots that you feel you can no longer learn from someone who still has much to offer.

▪ Immediately after finishing Pete’s book, I emailed Wyatt and let him know that I was interested in being mentored. That was an uncomfortable email to send, but the payoff was huge. Wyatt responded by suggesting that we meet periodically for breakfast to talk about what we were working on. Over the following year, Wyatt became a great mentor to me. Although we never Rubbed Elbows, my relationship with someone like Wyatt, a highly regarded software consultant and world-class cellist, was a huge confidence boost for an untrained, newbie programmer.

▪ Your apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of you, there will also be apprentices who have not yet reached your skill level. The other side of your search for mentors is that you must be willing to provide mentoring to those who seek it from you.

▪ Passing along what you have learned from your mentors is one of the ways in which you can begin the transition to journeyman status.

▪ Pick a tool, library, or community that has an active mailing list. Sign up to the list, but don’t post any messages yet. Just lurk. Over time you will start to understand the values of the community and learn which of the subscribers are patient teachers

▪ To keep your momentum going, especially in the absence of a full-time mentor, you need to be in frequent contact with people who are walking a similar road. Therefore you should seek out people like yourself who are also looking to excel

▪ The Long Road is not a road that anyone walks alone, and particularly during the years of your apprenticeship, you need camaraderie. This pattern is simple in principle, and for some people (our extroverted cohorts) it is simple in practice

▪ Some relationships are brief but career-changing; others are long-lasting and help Nurture Your Passion.

▪ the connection itself and the knowledge that there was someone else in his development organization who was dedicated to excellence made a huge difference in his work.

▪ Mentors are people who you want to emulate, and therefore can often feel a bit removed and sometimes intimidating. On the other hand, your community provides a safe environment for exploration and learning

▪ You can feel free to show each other what you’re learning and have no obligation to follow the other’s lead. This is different from a mentor-based relationship, where the apprentice might feel obliged to drop his interest in JavaScript and pursue Haskell simply because the mentor sees it as a superior language, disregarding the fact that the apprentice needs to learn JavaScript for his current project.

▪ List all the communities you could potentially join based on the tools you use, the languages you know, the people you have worked with, the blogs you read, and the ideas you are intrigued by. Identify which of those groups gather in the real world in your city. One by one, attend all these gatherings, and decide which groups seem most interesting

▪ I enjoy being given a certain amount of freedom in order to interpret or to come up with stuff, but I do enjoy collaboration. I seek and thrive on projects where I am going to learn from the people I’m working with.

—William Kempe

▪ Find ways to sit with another software developer and accomplish a hands-on task together, side-by-side. There are some things that can only be learned while you are sitting with another software developer to accomplish a shared objective.

▪ There will always be certain micro-techniques that you will only learn when collaborating closely with a colleague. These are usually seen as too trivial to mention when teaching, but their impact adds up.

▪ The development practice of Pair Programming is a concrete example of this pattern, and apprentices should look for opportunities to work on teams that use this technique

▪ While pair programming can be an excellent technique for learning, it is a complex activity and is not always an inherently positive experience.

▪ However, when used effectively, it is one of the most powerful ways to learn, particularly from mentors. So how do you know if pair programming is being used effectively? And what can an apprentice do about it?

▪ According to Richard Sennett’s The Craftsman, the ideal craft workshop is a place for “absorption into tacit knowledge, unspoken and uncodified in words” of the “thousand little everyday moves that add up in sum to a practice”

▪ For instance, you might collaborate with someone on an academic paper or a presentation or at an open source project’s sprint

▪ Sharing a whiteboard with someone who wants to use a very low-level tool to solve a problem you would automatically solve with a high-level language (or vice versa) forces you to temporarily think like that other person in order to communicate effectively. Even if you ultimately reject that viewpoint, you have gained a new way of looking at problems.

▪ Whether your experience rubbing elbows is positive or negative, you should Record What You Learn so that you can reflect on your experiences later on

▪ Find someone you know who has already expressed an interest in starting or contributing to an open source project. Arrange to spend one evening a week working together on the project. See how long the two of you can keep each other motivated

▪ Sweep the Floor

In the craft tradition, newcomers start as apprentices to a master craftsman. They start by contributing to the simpler tasks, and as they learn and become more skilled, they slowly graduate to larger, more complex tasks.

—Pete McBreen, Software Craftsmanship

▪ Volunteer for simple, unglamorous, yet necessary, tasks. This is a good way to contribute to the team’s success early on by showing that you can do a high-quality job even when it doesn’t seem to matter

▪ When I started my apprenticeship, I did not know how to write software. I had written some code to create simple programs and scripts for fun. When I started my software apprenticeship out, there were few places I could provide value to the company’s business. I could not write software and could obviously not teach others how to write software.

▪ Typically, you’ll want to focus on the edges of the system where there is less risk, rather than the core where there are usually many dependencies and lots of complexity. Jean Lave and Etienne Wenger observed apprentices in diverse industries and found that “a newcomer’s tasks tend to be positioned at the ends of the branches of work processes, rather than in the middle of linked work segments” (Situated Learning, p. 110).

▪ Of course, Sweeping the Floor can be tough to swallow if you have spent a lot of time and money on a computer science education. In theory, you’ve already paid your dues by pulling frequent all-night debugging sessions and enduring countless menial assignments from your professors.

▪ Unfortunately, in the workplace your education is worth less than you might think. Sure, there are plenty of organizations that make a computer science degree a high priority when they’re hiring people, but getting hired is different from joining a team. Once you’re in the door, all that education is doing for you is raising people’s expectations about what you’ll deliver on your first day (and hopefully it prepared you for that first day!).

▪ The same can be said if you are a self-taught person who “paid your dues” on previous projects.

▪ Regardless of where you came from, when you join a new project you are starting from square one. You should take this opportunity to send a message to the team that you want to contribute, even if it means taking on unsexy tasks

▪ Humility is one of the foundations of a successful apprenticeship. Combined with ambition, humility will help keep you focused and progressing in the right direction

▪ If we let ourselves, we shall always be waiting for some distraction or other to end before we can really get down to our work. The only people who achieve much are those who want knowledge so badly that they seek it while the conditions are still unfavourable. Favourable conditions never come.

—C.S. Lewis, “Learning in War-Time”, The Weight of Glory and Other Addresses

▪ We would build on that idea and assert that the core theme of an apprenticeship is learning and the dominant trait of a successful apprentice is a demonstration of her learning abilities. Apprentices are thirsty for opportunities to replace their ignorance with skill. This is no small feat when faced with the complexities of our work and the seemingly overwhelming amount of information that an apprentice must deal with. Beyond the fundamental act of learning Concrete Skills, an apprentice must also learn how to learn, for the transition to journeyman will certainly not remove the need for learning. One trait of a master craftsman is a willingness to set aside hard-won expertise in a specific domain in order to learn something new. Learning is a perpetual activity for those on The Long Road to mastery.

▪ The Perpetual Learning patterns are applicable for your entire career, but with the apprentice’s emphasis on learning, it is critical that these patterns be applied early on in your journey

▪ To transition to journeyman and ultimately master craftsman, you are going to need to be skilled at creating feedback loops, and also to be intimately familiar with your weaknesses.

▪ Expanding your ability to take in new information is a critical, though sometimes overwhelming, step for apprentices. You must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.

▪ Sign up for Google Reader (or another blog aggregator) and begin subscribing to software development blogs. With modern machine translation technologies, you don’t even have to restrict yourself to those who write in English.

▪ Start following some software luminaries on Twitter and pay attention to what they’re working on

▪ The people we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—and because of this they do get better. And then to complete the circle, the better they get the more they enjoy performing the basic moves over and over again.

—George Leonard, Mastery

▪ Beginners learn by doing, not through lecture. They practice, and practice, and practice.... By repeating and repeating these same exercises, we sharpen our skills, we train our bodies and our minds to respond to the disciplines of TDD and simple design. We wire, and rewire, and rewire, and rewire our neurons to react in the right way.[28]

—Robert Martin

▪ The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions. As Dave Thomas says of practicing, “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.”

▪ Short feedback loops need to be incorporated into your practice sessions. While practice is good in theory, if you’re not getting periodic feedback you’re probably developing bad habits

▪ The point is not to hone your memory, but to discover the nuances in even the simplest skilled activity. Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. So be careful what you practice, and constantly evaluate it to ensure you haven’t gone stale. Choosing the right thing to practice every day is a skill almost as important as the act of repeated practice. A good way to ensure you have interesting exercises to use in your practice sessions is to trawl through old books like Programming Pearls, More Programming Pearls, or Etudes for Programmers.

▪ Experience is built upon failure as much as (if not more than) success.

▪ You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything

▪ Only by attempting to do bold things, failing, learning from that failure, and trying again do we grow into the kind of people who can succeed when faced with difficult problems

▪ Budget for failure by designing and building toy systems that are similar in toolset, but not in scope to the systems you build at work

▪ If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure

▪ Just as the three-ball juggler would not attempt to juggle five balls during a performance, software developers need a safe place to make mistakes.

▪ When implementing the Breakable Toys pattern, make your systems relevant and useful to your life as an apprentice. For example, build your own wiki, calendar, or address book. Your solutions might be massively overengineered for the problem they’re solving, and probably could easily be replaced by something off the shelf.

▪ However, these projects are where you are allowed to fail. They’re the projects where you can try ideas and techniques that might lead to catastrophic failure. But the only one who can be hurt by their failure is you.

▪ These are your Breakable Toys. As you carry them with you from job to job, some of them will become living embodiments of your craftsmanship. Despite that, remember that they’re toys and as such should be fun. If they’re not fun, then after the initial burst of enthusiasm they will gather dust while you focus your energies on the things you actually enjoy building.

▪ The Breakable Toys pattern is similar to Be the Worst, but that pattern is about finding a team where you can grow. Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects

▪ The best way to prepare [to be a programmer] is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and fished out listings of their operating system.

—Bill Gates, Programmers at Work

▪ Seek out other people’s code and read it. Start with the applications and tools you use every day. As an apprentice, one of the beliefs that can hold you back is the idea that the people who built the tools that you depend on are somehow different or special or better than you are. By reading their code you can learn to program like them, and more importantly, you can start to understand the thought processes that created the infrastructure that surrounds you.

▪ As you work through the codebase, you will inevitably come across decisions that you passionately disagree with. Ask yourself if perhaps the developers knew something you don’t or vice versa. Consider the possibility that this was a legacy design that needs to be refactored away, and think about whether putting together a toy implementation of the feature might be educational.

▪ A common approach among the programmers we interviewed involves joining a team or project that uses code reviews or pair programming. These practices create environments in which the programmers could safely spend time reading other people’s code, having others read their code, and learning from each other. These groups tend to produce extremely strong programmers.

▪ Other environments, such as most academic computer science departments, tend to overlook the fact that working programmers spend far more time reading code than writing code.

▪ They take this approach because making every student reinvent the wheel creates artifacts that are easy to grade.

▪ However, training yourself to be better at the task that takes up most of your working day is an optimization that yields greater rewards in the long run

▪ By reading a wide variety of good, bad, and indifferent code written by other people you can start to learn about the idioms and subtleties of your particular language community

▪ Over time, this will develop your ability to divine people’s intentions from the code they have written. It will also help you learn to deal with those occasions when the two have diverged.

▪ These skills will make you a more valuable part of a team, because you’ll be able to work on other people’s code without always having to rewrite it because you can’t tell what it does.

▪ One of the problems with the field of software development is the lack of teachers

▪ This offers an opportunity to learn from other people’s mistakes and to acquire a more vital skill than mere code reading: the ability to learn without being taught.

▪ Self-examination is hard, but I believe we can learn more from studying our failures than from our successes.

—Norm Kerth, Project Retrospectives

▪ Become a reflective practitioner of software development. This involves regular introspection into how you are working. Consider whether your practices are novel, innovative, or outdated. Ask yourself questions about the things that the rest of your team takes for granted

▪ If there is something particularly painful or pleasant about your current work, ask yourself how it got that way, and if things are negative, how can they be improved?

▪ The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways.

▪ One technique that’s useful in making this kind of reflection explicit is to use something like a Personal Practices Map. This is an idea that Joe Walnes introduced at London’s Extreme Tuesday Club. It involves people consciously writing down the things they do and the connections between them.

▪ After everybody has written down their practices, the group discusses the practices that have been identified. If you take a look at the web page “Maps of People’s Personal Practices,” [32] you will see maps created by Ade and several other developers.

▪ Reflect on the practices, processes, and techniques they use to see if they can be connected to other parts of your experience. Even as an apprentice, you can discover novel ideas simply by closely observing more experienced craftsmen as they go about their work.

▪ In 2004, Dave was part of an XP team that contained several world-class developers. They had a fairly standard style of pair programming: one guy would write a test and slid the keyboard over to his pair, and his pair would make the test pass, immediately write a test, and slide the keyboard back to the first guy. The first guy would pass the test and so on. This style of pair programming was never really discussed; it just emerged out of their respective experiences.

▪ The Agile community has adopted a version of this process. Driven by Norm Kerth’s book Project Retrospectives, it involves the team periodically gathering to look back on the state of the project in order to find ways to improve

▪ Kerth’s prime directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”[33]

▪ If you hang on long enough, people will start calling you “experienced,” but that should not be your goal. All experience indicates is that you have been able to survive. It does not indicate the amount you have learned, only the time you have spent. In certain parts of our industry, it is quite easy to repeat the same year of experience 10 times without making significant progress in your abilities. In fact, this sometimes can turn into anti-experience: the phenomenon where every additional year or experience merely reinforces the bad habits you have picked up.

▪ This is why your goal should be to become skilled rather than experienced.

▪ Draw a Personal Practices Map for your working habits. Concentrate on the connections between any practices that have not changed in a while. Ask yourself how your map would change if you discovered that one of those practices was actually counterproductive

▪ You should not also underestimate the power of writing itself....You can lose your larger sense of purpose. But writing lets you step back and think through a problem. Even the angriest rant forces the writer to achieve a degree of thoughtfulness.

—Atul Gawande, Better

▪ Those who do not learn from history are doomed to repeat it.

▪ This pattern is similar to Share What You Learn, but there the emphasis is on preparing to become a journeyman by improving your ability to communicate with honesty and humility. Here the emphasis is on preserving the route you took to mastery so that in future you can extract new lessons from it.

▪ Furthermore, teaching is a powerful learning tool for the person doing the teaching, perhaps even more so than for the students. Thus the old saying “When one person teaches, two people learn.”

▪ You can’t tell if you’re suffering from “unconscious incompetence” since, as Justin Kruger and David Dunning put it in their article of the same name, those who are unskilled are often unaware of it. Moreover, the less skilled you are, the worse you are at assessing the skills of yourself and others. Success or failure tends to come as a surprise, and what little feedback you receive is an abrupt shock to your self-assessment instead of a support mechanism to help you improve.

▪ Your self-assessment is only relative to the abilities you used to have, and will always lack objectivity. The teams you work with can easily skew your sense of your own competence. Being on an above-average team can either make you feel like a superstar when you’re really more of a backup singer, or destroy your self-confidence when everybody seems so much more competent than you. On the other hand, a below-average team can make you feel complacently smug

▪ Create mechanisms for regularly gathering more or less objective external data about your performance. By soliciting feedback early, often, and effectively, you increase the probability that you will at least be conscious of your incompetence

▪ Another way of gaining feedback is to ask people how they think you are doing; for example, contact people who interview you for a new job or promotion and ask them their opinion of you. Even if you didn’t get the job, you can gain a lot from being told precisely why you were turned down. Sometimes this feedback will reveal facets (both positive and negative) of your personality that you were unaware of.

▪ All of the mechanisms described above will be useless if you haven’t developed the ability to process the raw data. For instance, if your employer provides annual reviews, you have to be able to separate the wheat from the chaff in order to get to the useful feedback.

▪ Criticism on its own is seldom useful feedback because it doesn’t tell you what is expected of you. Other kinds of bad feedback include feedback that is more about the other person than you (e.g., “Do this because I did it when I was your age”), that is really disguised advice, or that is what Dave Winer calls “stop energy.”

▪ So what does useful feedback look like? Useful feedback is data that can be acted upon and that gives you the option of doing more or less of a certain behavior. If you can’t do anything about it, then it’s not useful feedback. Or at least it’s not useful today. If your circumstances change it may suddenly become highly relevant.

▪ It’s also important to be aware of the distinction that systems thinkers make between reinforcing and balancing feedback. Reinforcing feedback encourages you to do more of something. Balancing feedback encourages you to do less of something. By combining the two types of feedback, a system can be kept relatively stable by making lots of small adjustments.

▪ Successful apprentices learn to create situations where they can quickly and frequently receive data about whether they need to do more or less of an activity

▪ This often means learning to communicate your ideas and listening without interrupting

▪ Acquiring the ability to avoid defending your current level of knowledge in favor of paying careful attention to any feedback is one of the ways in which this pattern overlaps with The White Belt.

▪ The hardest thing I found was that there are not many people out there that like to tell you you’re making mistakes, so half the battle is trying to find someone who will tell you as soon as possible

▪ Upon reflection, I think an apprentice probably shouldn’t work on not making mistakes early as much as they should be working out how to identify the mistakes you make

▪ Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and a constant searching for new solutions.

—Atul Gawande, Better

▪ This is not about wallowing in self-pity about past mistakes nor is it an exercise in seeking perfection. Instead, the goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure. Armed with that self-knowledge, you can make conscious choices and temper the tendency toward idealism when applying Draw Your Own Map with an awareness of your boundaries and limitations.

▪ By becoming conscious of the things that trip you up, you allow yourself the choice between working to fix these problems or cutting your losses

▪ Accept that there will be some things that you’re not good at, or that would require a disproportionate investment of time and effort in order to make a small improvement

▪ This feeds into your accurate self-assessment, but it also enables you to set realistic limitations on your goals. You can’t excel at everything, and accepting these limitations is important, as it forces you to consciously acknowledge distractions and focus on your goals

▪ Most people will discover corner cases they hadn’t thought of and trivial little errors. Before you fix these errors, try to understand how they could have occurred in something you were sure was perfect. What does that tell you about yourself? Write down what you learn in the iterations between what you thought was perfect code and the point when you have code that actually compiles and passes all the tests.

▪ Perpetual Learning can be viewed as a blessing or a curse. Learning something new can be painful, especially when it is done under pressure and with little guidance

▪ Yet, like the athlete who must endure muscle soreness after strenuous workouts, the software developer endures the mental dissonance that comes with learning something new

▪ That dissonance can become a welcome sign of progress. Self-reflection, identifying failure through feedback loops, and learning your weaknesses all appear negative on the surface, but these patterns are helping you to reduce your ignorance.

▪ He’d no longer be a grade-motivated person. He’d be a knowledge-motivated person. He would need no external pushing to learn. His push would come from the inside.... Motivation of this sort, once it catches hold, is a ferocious force.

—Robert Pirsig, Zen and the Art of Motorcycle Maintenance

▪ We live in an age of abundant information. The invention of the printing press ushered in an era that allows even some of the poorest members of society to acquire the knowledge, and therefore the power, to change their circumstances

▪ The ever-expanding World Wide Web and an unending series of technical innovations continue to lower the barriers to virtually any information we could ever want

▪ No one can learn everything at once, but no principle or rule prevents the apprentice from learning a little of this today, a little of that tomorrow, things in some order no one ever thought of before, or learning to the point where he wants to stop and then switching to something else. He need not, when he wants to learn a certain procedure, wait until it’s time in a prearranged schedule; nor need he learn something he is not ready for, thinks uninteresting, frightening, or unnecessary. The learner makes his own curriculum.

—Howard S. Becker, “A School Is a Lousy Place to Learn Anything In”

▪ One of the most valuable things you can gain from any book is a list of other books that are worth reading. Over time, you will discover that certain books keep popping up in bibliographies, and you should move those books to the top of your reading list. Other books will drop down. Since your reading list is actually a priority queue, you will eventually realize that certain books have fallen so far in the ranking that you will probably never read them. This is fine. The purpose of this pattern is to give you a way to prioritize and filter the flood of potential knowledge.

▪ It is important to remember that this is your Reading List. It’s great to be influenced by the suggestions of others, but only you truly know your current context. Therefore, you should be the one making the choice about what to study next

▪ There should be seasons of The Long Road when you have (or take) the opportunity to read a significant number of books

▪ You can always say to yourself: “If I mastered EJBs then I can handle metaclasses.”

▪ Find out who first came up with the ideas and understand the problems they were trying to solve. This kind of context usually gets lost in translation as the idea gets passed around. Sometimes you will find that seemingly new ideas were abandoned long ago, often for good reasons—but everybody has long since forgotten about it because the original context has been lost

▪ Many times you will find that the original source of an idea is a much better teacher than the chain of people who have been selectively quoting each other for years

▪ Whatever happens, tracing the lineage of ideas you have found helpful is an important exercise, and a habit that will serve you well through the years as you attempt to learn new things

▪ When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge

▪ For example, people often run into trouble with regular expressions because they only acquire a superficial understanding. You can get along just fine for years, maybe even decades, without really understanding the difference between a Deterministic Finite Automaton and a Nondeterministic Finite Automaton. Then one day your wiki stops working. It turns out that if your regular expression engine is implemented recursively, then on certain inputs that require backtracking it will run for a very long time and eventually throw a StackOverflowException.

▪ Instead, continue to seek out opportunities to Be the Worst. Challenge yourself to assemble useful tools from these fundamental building blocks, rather than just basking in your ability to take things apart.

▪ At those times, you have to decide if your productivity is more important than the team’s productivity. Just because you know Struts like the back of your hand doesn’t necessarily make it easy to use.

▪ You know the problems these tools solve and the problems they cause. Consequently, you know where not to use them, which is as important as knowing where they are best applied.

▪ In a time of drastic change it is the learners who inherit the future. The learned usually find themselves equipped to live in a world that no longer exists.

—Eric Hoffer, Reflections on the Human Condition

▪ Letting go of familiar and valuable tools is a painful process, but it’s a skill that you need to acquire.

▪ We can guarantee that the tools you use as an apprentice will be obsolete by the time you become a journeyman. In time, all of your favorite tools will become junk

▪ For your career to prosper, you must learn to acquire and abandon familiar tools with ease

▪ In your formal education, you may have gotten used to having a curriculum presented to you and churning through it with little to no thought about whether these were the best books to be reading, and in the best order

▪ Learning to enjoy the learning process itself will serve you well in the ever-changing technology landscape that keeps us perpetually on our toes.

▪ The violins and cellos that were made in the workshop of Antonio Stradivari in the 17th and 18th centuries are considered the finest ever made. They regularly sell for millions of dollars, and over the last 300 years there have been many attempts to reproduce them

▪ masters should be pestered to explain themselves, to dredge out the assemblage of clues and moves they have in silence within” and that we should push them to make the tacit explicit. Without apprentices who are enthusiastic to the point of being pushy, software craftsmanship will continue to exist only in isolated pockets of quality that have formed around small groups of peculiarly talented developers.

▪ Software development is a craft precisely because we don’t understand it well enough to make it a codified discipline like science or engineering. Despite the best efforts of groups like the Software Engineering Institute and the Agile Alliance, our field is still one where individual skill is often the most significant determining factor in a project’s success. When we use the word skill, we don’t just mean how much computer science you know or the effectiveness of your development process or how much experience you have. We mean the union of all the things it takes to deliver working software. It includes, but is not limited to, all the lessons you have learned from the patterns in this book.

▪ Moreover, most programmers think they are above average. The sad reality is that, due to the skewed distribution of skill illustrated by the following chart, most programmers are actually below average

▪ When we say that something is a craft, one of the things we mean is that it is a discipline and a tradition that places a high value on skill

▪ This includes acquiring, growing, and eventually transmitting that skill. We believe true mastery is shown in the effect you have on others by transmitting your superior skill.

▪ In his book entitled Better: A Surgeon’s Notes on Performance Dr. Atul, Gawande tells the story of the physician Ignac Semmelweis (Better, p. 15). In 1847, Semmelweis worked out that “by not washing their hands consistently or well enough, doctors were themselves to blame” for the leading cause of death among women who gave birth in hospitals. He introduced simple practices, like asking doctors to wash their hands with chlorine in between seeing different patients, that reduced the mortality rate from 20% to 1%. However, in the process of achieving his superior results, he managed to alienate or offend his entire profession. Things eventually got so bad that his colleagues started to deliberately avoid washing their hands just to defy him.

▪ Semmelweis’s failure to properly explain his ideas or convince others eventually cost him his job, and also cost many people their lives in the 20 years it took before Joseph Lister discovered the same ideas. As Gawande puts it, “Semmelweis was a genius but he was also a lunatic, and that made him a failed genius” (Better, p. 17).

▪ In the same way, many of the patterns and ideas in this book will generate conflict and resistance. This is partly because there are always people who benefit from the current situation and who fear they may lose something if the situation improves

▪ One of the ways in which we can spot masters is that their students eventually surpass them in ambition and in achievement

▪ As an apprentice, you should aim to become better than your teachers. And if they are good teachers, they should try to help you achieve that goal

▪ Assessing the work of someone who is more skilled than you are is notoriously difficult. You won’t understand why the things she makes look so easy are so hard. At best, you will be able to tell that this person is more skilled than you. But that isn’t enough for mastery. Being ahead of you on the path doesn’t make someone a master.

▪ Unfortunately there is no other way for a new craft to evolve. All crafts begin by stumbling into the world with unsatisfactory definitions and unclear standards. We have to put up with these until we have built up a community and a body of knowledge that can clearly demonstrate the skill of its practitioners.

▪ On a scale of 1 to 10 we’d rate ourselves as 9s, but sometimes we meet people who make us realize that the scale goes all the way up to 100

▪ Bob asserted that we need to apprentice these young people, these graduates and newcomers. He asserted that the most effective learning situation is one where a small number of apprentices work alongside an even smaller number of journeymen, who are receiving guidance from a master craftsman. It was music to my ears until Bob polled the audience for anyone who was working in that environment.

▪ I proudly raised my hand, but my heart sank as I looked around and realized I was the only one raising my hand

▪ Apprenticeship is more than simply hiring entry level people. Apprenticeship is coupling an apprentice to a journeyman

▪ That doesn’t mean they’re pair programming all the time, but it does mean that the journeyman is overseeing the apprentice’s progress and that the apprentice has an experienced developer in close physical proximity to turn to for guidance

▪ A central tenet of the craft model is that it is hard to pick up a skill just by being told about it. You actually have to practice the skill under realistic conditions and under the watchful eye of an experienced practitioner who is providing feedback.

▪ What do I attribute our success to?

▪ Co-location: Nothing beats face-to-face teamwork

▪ Pair programming: Nothing beats side-by-side development

▪ Test-driven development: Nothing beats ping pong programming with tiny feedback loops

▪ Agile principles: Constantly re-evaluating our reality with the principles we hold and readjusting our process accordingly