Chapter 4. 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!

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

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.

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!

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.

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.

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.

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.

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[25] 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.

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.

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.

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.



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

[22] Resignation and postmortem: http://www.jwz.org/gruntle/nomo.html.

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

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

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