Apprenticeship Patterns

CHAPTER FOUR

Accurate Self-Assessment

One of the primary risks for someone who learns quickly is becoming a big fish in a small pond. While there is nothing inherently wrong with small ponds or big fish, it is critical for the big fish to be aware of other ponds within the vast global network of ponds, and more importantly, the existence of enormous fish, fish that even exceed the size of your little pond.

The talented and hard-working apprentice must not become self-satisfied with his success. It is very easy to rise above the mediocre in the field of software development because too many people become satisfied with staying only slightly ahead of the curve. You must fight this tendency toward mediocrity by seeking out and learning about other teams, organizations, journeymen, and master craftsmen that work at a level of proficiency that an apprentice cannot even imagine.

You must be willing to let go of your perceived competence and allow yourself to recognize that you have traveled only a short distance on The Long Road. Your goal isn’t to become better than the “average developer.” 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 Worst

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

Tractate Avot

Context

You have Unleashed Your Enthusiasm and taken every opportunity to learn new skills. As a result, you have outgrown your team and possibly your entire development organization.

Problem

Your rate of learning has leveled off.

Solution

Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow.

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.”¹ Pat’s advice struck a chord with Dave, and was one of the reasons he started writing this book.

DAVE FINDS A BETTER TEAM

My first programming job was at a dot-com startup. Five months later, the dot-bomb exploded. After the smoke cleared, I landed in the IT department of a large nonprofit organization. It was a great place to weather the downturn for a few years, but compared to my former employer the development pace was excruciatingly slow. Two years later I had learned a ton, but I was unchallenged and had lost hope for significant organizational improvement. Acting as the technical architect of my team initially provided some great learning experiences, but the absurdity of me in an architectural role drove me to look elsewhere for work. The sole purpose of my job search was to increase my rate of learning and the best way I knew to do that was to surround myself with exceptional developers. A year later I was fortunate enough to find myself on a team with several world-class developers. It was an incredible challenge, but a priceless opportunity.

—David H. Hoover

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. This makes Reflecting as You Work and building Breakable Toys particularly important for people who are the worst on their team. Both provide opportunities to take a step back from the team environment to see what habits, techniques, and knowledge you’re picking up from Rubbing Elbows with your more experienced teammates.

The drawing shows that as the weakest member of the team, you should be working harder than anyone else. This is because the goal is not to stay the weakest, but to start at the bottom and work your way up. You do this by consciously finding ways to improve and mimicking the stronger developers until you are on the same level as the rest of the team. Without this conscious attention to learning from the team, you will face several risks.

First, there is the risk that you will drag the team down. Second, since good teams won’t tolerate (for long) someone who is just a passenger, you run the risk of being fired if you’re so far behind that you can’t catch up or don’t seem to be catching up quickly enough. Another side effect of joining a strong team is that you can end up feeling bad about yourself and your skill level unless you’re actively honing your skills. At its best, this can motivate you to improve. But like any “sink or swim” strategy, when it fails you will find yourself drowning. This is why it is essential to Create Feedback Loops so that you can tell when you’re in trouble. This feedback will tell you if the team is too far ahead of you or hostile to people trying to work their way up.

Like Stay in the Trenches, 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.

There is a selfish aspect to purposely joining a team as the worst member. To counter this, complement Be the Worst with Sweep the Floor and Concrete Skills. Sweep The Floor means to explicitly seek out menial tasks in order to directly add value to the project. Developing Concrete Skills will increase your contributions to the development effort and is fundamental to your role as an apprentice. Without these kinds of contributions, this pattern can lead to strong teams being fatally weakened, as Jamie Zawinski points out in his infamous open resignation letter from the Mozilla project.² Ultimately, your (rapidly) increasing contribution to the team is why these strong teams will take the risk of bringing you on board.

Jake Scruggs says it well when he speaks of his summer apprenticeship at Object Mentor:

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

Collaborating with great developers will help you maintain a more accurate self-assessment as well as provide help in Finding Mentors. However, this pattern is usually inappropriate for more experienced developers who are looking to become journeymen. At that stage, you should be looking to mentor novices and give others the opportunities you have been given.

BRIAN’S CHOICE

Joining Obtiva put me back at the bottom of the food chain. Now, I’m a green Software Apprentice and it’ll be awhile before I head a team of developers. Instead of leading I’ll be learning. I’ve been demoted.

Why would someone choose that?

First, being the worst on a team of outstanding developers can’t be compensated for with environment, equipment, or money. You can’t compensate for learning next to people who have already traveled the path and know how to avoid the holes on the road ahead. Pairing with great software developers is invaluable. If you’re new to programming and have not had the opportunity to pair then you need to demand the experience.⁴

Action

List all the teams you know. Include open source projects, other departments, and other companies. Sort these teams by skill level, then identify a team that is open to new members who want to work their way up. This may require you to join several mailing lists and ask various people questions in order to gauge their relative skill level. At the end of the process you will be better at comparing skill levels, and may even have a new team!

See Also

“Breakable Toys”, “Concrete Skills”, “Create Feedback Loops”, “Find Mentors”, “Reflect As You Work”, “Rubbing Elbows”, “Stay in the Trenches”, “Sweep the Floor”, “The Deep End”, and “Unleash Your Enthusiasm”.

Find Mentors

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

Context

You have realized that you’re not the first person to walk the path and that you are spending a lot of time exploring blind alleys.

Problem

You’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance.

Solution

Seek out those who have gone ahead of you and strive to learn from them.

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.

Our field is very young and therefore has few recognized masters. 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

When trying to Find Mentors, an apprentice must remember that we’re all walking The Long Road and no one knows everything. 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.

DAVE FINDS A MENTOR

By the summer of 2002, I had been programming for less than two years and was starting to get glimpses of the vast difference between a beginner and a super-experienced practitioner. Reading Pete McBreen’s Software Craftsmanship that summer compelled me to find a mentor. The book helped me see that if I wanted to become a great developer, I was going to have to reach out to more experienced developers and coordinate my own apprenticeship. I was at the height of Expanding My Bandwidth and had recently started attending ChAD, the Chicago Agile Developers user group. It was there that I (uncharacteristically) introduced myself to Wyatt Sutherland, the group’s organizer. 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. Wyatt’s mentoring was pivotal in my progress in agile software development, and propelled me to believe that I had the talent to join a development organization like ThoughtWorks.

While simple in concept and exceptionally important for your apprenticeship, finding people to guide you can be difficult. Sure, it’s easy to locate authors, conference speakers, committers on popular open source projects, and developers of successful websites. But the difficulty is twofold. First, these people may not be interested in mentoring; and second, reaching out to ask for something as strange as “apprenticeship” can be incredibly intimidating. This is similar to the risks associated with diving into The Deep End. Just keep in mind that the risk of being rejected or thought strange by a potential mentor is low, while the potential payoff is huge. Even if the person is not interested in taking you on as a full-time apprentice, offering to take her out to lunch would be time and money well spent. If you are serious about achieving mastery, be tenacious about finding mentors to guide you. You would be hard-pressed to find any top-notch developers who cannot recall the powerful impact that their mentors had on them.

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.

Action

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. When you have this understanding, seek out the members of this list at the next conference and see if they would be interested in providing you with some informal advice about the lessons they have learned.

See Also

“The Deep End” and “The Long Road”.

Kindred Spirits

Nothing is more powerful than a community of talented people working on related problems.

Paul Graham, Hackers & Painters

Context

You are months or years into your apprenticeship and you find yourself discouraged by the culture of your development organization.

Problem

Organizational cultures that encourage software craftsmanship are rare. You find yourself stranded without mentors and in an atmosphere that seems at odds with your aspirations.

Solution

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. For others, however, it can be difficult. Some relationships are brief but career-changing; others are long-lasting and help Nurture Your Passion. The following stories provide examples of the power of Kindred Spirits.

• Dave read Extreme Programming Explained in 2002 and dove headfirst into the XP and Agile community. He paid his own way to attend XP/Agile Universe 2002, which was conveniently hosted in a nearby suburb of Chicago. While at the conference, Dave met Roman, whom he had already been introduced to online through a local user group mailing list. Dave and Roman agreed to meet for lunch to discuss Joshua Kerievsky’s book-in-progress Refactoring to Patterns. Roman worked at a large, multinational bank and Dave worked at an old, bloated nonprofit; not surprisingly, they both enjoyed the escape from the mediocrity of their respective development organizations and met every week for several years. They didn’t end up discussing Joshua’s book (because Dave first needed to read Refactoring and Design Patterns) but spent their time in all sorts of ways, discussing other books like Peopleware, learning Ruby on Dave’s laptop, sharing horror stories, and offering each other solutions to the various problems they encountered over the years.

• Steve Tooke told us a story of meeting Shane in 2004 while working for a company in Manchester, England. Steve was an enthusiastic young programmer, and Shane was an experienced developer based in New Zealand. Although they were thousands of miles apart, their interactions were career-altering for Steve. Shane introduced him to books like Design Patterns, which gave them a shared language to describe the object-oriented designs they were working on together. The communication roadblocks of being separated by many time zones meant that Shane couldn’t provide much direct mentoring, but for Steve, 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. Perhaps you are interested in advanced JavaScript, and one of your Kindred Spirits is investigating Haskell. 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. Keep this in mind and complement the Find Mentors pattern with a community of Kindred Spirits with whom you can let down your guard.

Despite the many benefits of a community of like-minded folk, you must also be aware of group-think. Force yourself to retain the capacity to ask questions that shock your community. Try to use that little bit of intellectual distance to generate the kind of respectful dissent that will keep your community healthy. Your community’s health can be measured in the way it reacts to new ideas. Does it embrace the idea after vigorous debate and experimentation? Or does it quickly reject the idea and the person who proposed it? Today’s dissident is tomorrow’s leader, and one of the most valuable services you can provide to your community is defending it against those who believe that marching in lockstep is the price of membership.

Action

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.

What if none of the groups regularly meet near you? In that case, you’ve just been given a golden opportunity to create one of these gatherings. Start a regular meetup of software craftsmen in your region. It’s a lot less work than you would think. Just don’t make the mistake of restricting the membership or the topics too early. Instead, advertise anywhere and everywhere that software developers in your region might see it.

As your group grows, feel free to explore a wide and bizarre range of topics until you have a core group of irregulars. Over time, that self-selected group of irregulars will define the nature of your group. You won’t always have the same people attending every fortnight—that’s what makes them irregulars. Groups like the Extreme Tuesday Club have a few hundred “members”; on any given Tuesday there will only be a dozen or so people in attendance. If your group becomes large enough and energetic enough, it will sustain itself even when you are not there. That’s when you know you have a community.

See Also

“Find Mentors”, “Nurture Your Passion”, and “The Long Road”.

Rubbing Elbows

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

Context

While you may have mentors and kindred spirits that you meet with periodically, when it comes to developing software, you work alone.

Problem

Your productivity has reached a plateau, your learning is stagnating, and you have the feeling that there are superior techniques and approaches to the craft that are eluding you.

Solution

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.

This pattern can be closely related to Kindred Spirits. This was the case for Dave, who found an ally in Roman and then literally rubbed elbows over lunch as they learned together about technologies like the Ruby programming language and Eclipse plug-in development. Yet, even if Roman had not been a kindred spirit, Dave would still have benefited by working side-by-side with a talented programmer, even on pet projects. 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. Collaborating with Roman was critical for Dave’s progress as a developer, since he rarely had the opportunity to work with talented developers at that time in his career.

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?

You will often feel lost or far behind your counterpart when you’re implementing this pattern via pair programming. This does not mean pair programming is failing—it simply means you need to either slow things down by asking questions or endure the feeling of being lost and try to pick up the bits that you do understand. But if you feel chronically behind, week after week, and you’re beginning to despair, then it’s time to make a change. You may be stuck with a poor pair programming partner, or your partner may need some suggestions to improve your experience. As an apprentice, you may not have much power to change your situation, but if you’re on a project with more than a few people, you can likely find an opportunity to alternate days or weeks between pair programming partners. This rotation may help jiggle you out of your troublesome situation and get you back on the path of progress. Additionally, if you’re practicing test-driven development, you can suggest Ping-Pong Programming⁵ as a way to increase your participation.

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” (p. 77). Since such ideal environments are now so rare, we have to use the Rubbing Elbows pattern as a modern-day substitute. The applications of this pattern are not limited merely to pair programming. The goal is to find ways to expose yourself to the daily working habits of other skilled people, and observe the ways in which they gradually refine those habits into even greater skill. These habits extend beyond coding and into all aspects of software development.

For instance, you might collaborate with someone on an academic paper or a presentation or at an open source project’s sprint. Or, as happened to Ade, you might find yourself volunteering to help somebody who wants to apply graph theory to design the dependency management component of a content management system written in Unix shell script! 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. That perspective may be just the right solution to some future problem, even if in the short term you find it jarring.

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. Someday you will likely be in the same position as your pair programming partner, and your past experiences will give you precious insight into the mindset of the junior person sitting next to you.

Action

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. The strains of a busy life will inevitably weaken the motivation behind your collaboration; when that happens, you must adapt and find ways to keep the project going until that motivation returns. Of course, if motivation never returns, it is up to you to seek out a new partnership where you can learn new things.

See Also

“Kindred Spirits” and “Record What You Learn”.

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

Context

You are a new apprentice on a project.

Problem

You’re unsure of your place on the team, and the team is unsure of you. You wish to find a means of contributing to the team’s work, earning the team’s trust, and growing in stature as a craftsman.

Solution

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. Of course, skimping on quality in the unglamorous portions of any project often leads to trouble later on, when it turns out that the unglamorous parts of the project are vitally important.

PAUL LITERALLY SWEEPS THE FLOOR

I had the privilege to be trained in a formal software apprenticeship environment. Object Mentor hired me when I was seventeen and brought me back every summer and winter break during college. 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.

At the time, Object Mentor employed many of the successful eXtreme Programming leaders to teach a course about XP. As the star-struck young apprentice, I was commissioned to build the perfect pair programming tables they had designed. Also, I would put together the computers, install the correct software for the exercises, and clean up the room. These tasks helped me to build confidence in being part of the team, part of the company. As I struggled learning to write code, I could still contribute with specific talents and tasks that needed less skill.

Slowly, as my apprenticeship progressed, I would take on more technically challenging assignments. However, they were still often the ones you would assign to the low man on the totem pole. Tasks like moving servers, figuring out the backup systems, and updating content on the website. These tasks were helpful for me to get small victories at a time when it was hard to get those victories writing code.

Playing the role of a traditional apprentice also helped me to build up humility and respect for the senior craftsmen. I remember Uncle Bob Martin came into a room, saw the trash overflowing, and changed the garbage bag. My mentor scolded me and appropriately said that it is not the job of the master craftsman to take out the garbage. It is a sign of respect and piety that was an important lesson for me to learn.

—Paul Pagel, email

Unlike Paul, most apprentices won’t literally be sweeping the floor. However, the tasks you volunteer for will matter just as much to the ongoing health of the team.

Examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on. 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). These sorts of fringe tasks benefit the team, but they will also benefit you as an apprentice, because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. This experience will serve you well as a journeyman too, because any master who takes you on will understand how valuable it is to have someone to do the unglamorous work. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.

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.

There are a few negative consequences that may occur when you apply this pattern. One is that you may end up as the team’s gopher, condemned to do the menial tasks no one else will do. And while you’re unlikely to be seen as overstepping your boundaries due to the unglamorous nature of the tasks you’ve chosen there is a danger that you may not be able to turn your early success into a case for being given more challenging assignments. Alternatively, you may find yourself intimidated by doing anything other than Sweeping the Floor. There is also the danger that you may not be able to develop an appreciation for the bigger picture if you only work on piecemeal tasks with no wider coherence. If you find yourself in any of these situations, try to Nurture Your Passion, Unleash Your Enthusiasm, advocate for yourself, and look for every opportunity to prove yourself worthy of higher-level work.

Action

What’s the grungiest task that your team has been putting off for months? It will be the one that everybody complains about and that no one wants to tackle. Tackle it. And don’t just hold your nose and force yourself to do it; see if you can creatively resolve the problem in a way that exceeds people’s expectations and makes it fun for you.

See Also

“Nurture Your Passion” and “Unleash Your Enthusiasm”.

Wrapping Up

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. Without it, you’re susceptible to prematurely declaring your apprenticeship complete and missing out on some important lessons. Perhaps you feel proud of a significant project or subsystem you’ve delivered and you believe that it proves that you have become a journeyman. Perhaps. But have you delivered something significant on more than one platform? How much more would you learn if you tried your hand at a different language? Any ambitious apprentice’s natural instinct will be to try to race to the finish line, to become a journeyman as quickly as possible. Remember, though, that you are walking The Long Road, and this journey is not a sprint. Take the time to get the most out of your apprenticeship, and understand that whether you have been programming for three months or five years, you are still very much a beginner when it comes to software craftsmanship.

¹ Chris Morris’s blog, “Be The Worst.” Available at: http://clabs.org/blogki/index.cgi?page=/TheArts/BeTheWorst.

² Resignation and postmortem: http://www.jwz.org/gruntle/nomo.html.

³ Jake Scruggs, “My Apprenticeship at Object Mentor.” Available at: http://www.jikity.com/Blah/apprentice.htm.

⁴ Brian Tatnall, “New beginnings with Obtiva.” Available at: http://syntatic.wordpress.com/2007/05/18/new-beginnings-with-obtiva/.

⁵ David H. Hoover, “Ping-Pong Programming.” Available at: http://www.stickyminds.com/s.asp?F=S9101_COL_2.