Chapter 3. Walking the Long Road

It’s not just a question of conquering a summit previously unknown, but of tracing, step by step, a new pathway to it.

Gustav Mahler, musician and composer

Do you have training and achievement certificates hanging around your cubicle? Back when Dave had his very own cube and even less experience than he does now, he conspicuously piled a stack of certificates near his desk. The pile featured a Brainbench “master” certification in Perl and grew to include certificates proving that he had completed various multiday trainings in C, J2EE, Vignette, and ATG Dynamo. This small stack of pseudoparchment reassured him (and his organization) that he knew what he was doing. He had been “trained.”

Meanwhile, Dave had started to branch out and connect with the broader developer community through http://perlmonks.org and the comp.lang.perl.* newsgroups. It was in these groups that he discovered some exceptional Perl hackers. The hackers’ expertise was daunting, particularly because Dave could see that they were still learning, and fast. It began to dawn on him that he had barely scratched the surface of what it meant to be a great software developer. Over the following months, his pile of training certificates slowly disappeared beneath a larger pile of scratch paper and printouts of book drafts and tutorials.

Through his observations and interactions with a few of these exceptional hackers, Dave was captured by the learning process. Periodically he would catch a glimpse of the depth and breadth of the hackers’ knowledge and come away either discouraged or inspired—discouraged by how little he understood, yet inspired by the power of these hackers’ abilities. He threw himself into side projects and began to read anything he could get his hands on.

The more Dave learned, the more he recognized how far he had to go. Over the next few years he had the good fortune to collaborate face-to-face with some exceptional software developers. Dave saw that although these exceptional people were miles ahead of him, they were all walking the same road.

The Long Road

“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

To become truly good at programming is a life’s work, an ongoing enterprise of learning and practicing.

Ron Jeffries et al., Extreme Programming Installed

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

Context

We live in a culture that values overnight celebrity, rising stars, material wealth, and quick results. There are very few programmers around who can tell you what software development used to be like back in the old days. When you do speak to these veterans, they shake their heads at the latest industry fad that is repeating the mistakes they saw in their youth. The lessons appear to have been forgotten because there is so little knowledge transferred between generations of software developers.

Problem

You aspire to become a master software craftsman, yet your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills.

Solution

First, accept the fact that you may be considered a bit strange for what you want to become. Second, keep your focus on the long term. During your apprenticeship, value learning and long-term growth opportunities over salary and traditional notions of leadership.

People aspiring to become masters of software craftsmanship need to plan for the long term. This long (yet bright) journey will bring you a rich set of abilities. You will become skilled at learning, problem solving, and developing strong relationships with your customers. You will come to wield knowledge and technology as the samurai uses his short and long swords. You will come to comprehend and appreciate the deeper truths of software development. But all this will take time.

You should be prepared for the length of this journey. When you Draw Your Own Map, you should keep in mind the expectation that you will be a working software developer even when you are middle-aged. Let this influence the jobs you take and the scope of your ambitions. 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. No business or technical domain is closed to you. With an entire career devoted to the craft, it becomes realistic rather than vain to think about surpassing people like Donald Knuth or Linus Torvalds. The length of the journey merely multiplies the possibilities that are open to you. (Of course, people like Knuth and Torvalds won’t be staying still whilst you catch up to them!)

This pattern is not for people aspiring to become CIOs or project managers, or filthy rich. Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey. And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades.

We don’t want to give the impression that everyone must follow a single road (see Draw Your Own Map) or that this is the right road for every software developer (see A Different Road). Some people leave development permanently and become executives, testers, salespeople, or project managers. Some people leave technology permanently and enter into entirely different fields. These are all valid and beneficial roads to take, but this book and this pattern are not for those people.

If an Accurate Self-Assessment is the cornerstone of a successful apprenticeship, then The Long Road is the foundation. The transition from apprentice to journeyman is only the first of many steps along the path to mastery. Like a martial artist attaining the rank of black belt, a new journeyman realizes how much farther he has to go.

Software developers are fortunate. 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.

Action

Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.

Craft over Art

I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty.

Richard Stallman in “Art and Programming” [15]

Context

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

Problem

Although there is a proven solution available, your customer’s problem represents an opportunity to do something truly fantastic, providing you with an opportunity to create something beautiful that will impress your colleagues.

Solution

Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests.

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.”[16] 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. Walking the Long Road means you must balance these conflicting demands. 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. A craftsman values a fifty-line game that makes someone smile over a million-line game that pushes the frontiers of computer science but is unplayable.

Another aspect of craft over art is that your customers need you to produce satisfactory quality even when you don’t feel like it. A craftsman is unwilling to wait until inspiration strikes before she delivers artifacts that satisfy her customers. This has both positive and negative connotations. On the one hand, the craftsman is barred from the idyllic playground of art, where other people pay her to build the things she wants. On the other hand, she and her customers have the satisfaction of creating and using software that provides immediate value.

This pattern is not about doing merely what is expedient. It also encompasses the idea that a useful craft artifact always displays at least a minimal level of quality. 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. The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. 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.”[17] 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.

Action

In the next 24 hours, find an opportunity to do something useful rather than beautiful. This may be a straightforward choice, or it may involve a more subtle trade-off. The important thing is to make yourself aware of the issues discussed here when you choose what to do.

Another way to improve your awareness is to think of situations over the last year where you chose artistry over utility. How did that turn out? Write down what you think would have happened if you had made a different choice.

Sustainable Motivations

Anyone who has ever seen a programmer at work...knows that programming itself, if the programmer is given the chance to do it his way, is the biggest motivation in programming.

Context

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.

Problem

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

Solution

Ensure that your motivations for craftsmanship will adapt and survive through the trials and tribulations of The Long Road.

There will be days, weeks, and months when you love your job. You’ll chuckle to yourself, in awe that you actually get paid to develop software. The software you write will flow effortlessly from your mind through your fingertips, beautiful to behold in function and design. These are good and extraordinary days. In other words, they are not your ordinary days.

As Paul Graham so rightly says, the typical programming job will put you face-to-face with tedious, vaguely defined, and needlessly complex problems. Nasty, wicked problems. What’s more, you may also be faced with bureaucracy, difficult personalities, and spotty leadership. There will be days, weeks, and months when you question your commitment to the craft. When you are confronted with such problems, it is crucial that your motivations to program are aligned with walking The Long Road. Here are a few examples to illustrate the point:

  • You hate your programming job and you’re motivated primarily by money. You find yourself focusing on climbing the corporate ladder over honing your craftsmanship. But you are also motivated by your reputation as a technologist, and this allows you to endure long enough for your job situation to improve.

  • You’re motivated primarily by your enjoyment of programming, but you’ve had a few months when you can’t feel the love. You are seriously considering abandoning the profession. Fortunately, you are also motivated by money, and you think that programming is your best option financially right now. You stick it out for the money and eventually your love for programming returns.

  • Your work on open source projects is motivated primarily by a desire to build your reputation. While your projects provide value to users around the world, your status as a hacker has remained stagnant and you are considering abandoning your work. Yet, your belief in the importance of free software keeps you going. Your projects eventually blossom and your reputation grows.

Some programmers become inadvertently trapped by their motivations. In More Secrets of Consulting, Dorset House, Jerry Weinberg describes this phenomenon as the Golden Lock: “I’d like to learn something new, but what I already know pays too well.” The risk of the Golden Lock highlights the importance of aligning your motivations with The Long Road, which requires the ambition to achieve mastery. A desire for mastery should motivate you to be wary of Golden Locks as they inevitably present themselves. As you progress as a craftsman, you will be faced with tough decisions that will determine whether you have the freedom to stay on The Long Road or whether you will find yourself trapped in a Golden Lock. Two examples:

Obie Fernandez is an exceptional Java programmer whose reputation was built on his Java expertise. Obie had a decision to make in 2005: continue to grow his Java-expert status, or learn a promising new web framework (Rails) in an unfamiliar language (Ruby). Obie chose to focus on learning in order to expand his toolset. This is the mark of a craftsman. He set aside the safety of his Java reputation and became a Ruby newbie, avoiding a Golden Lock. Ironically, this decision allowed Obie to ascend to even greater heights than his previous Java-expert status, and eventually led him to start the web application development firm Hashrocket.

On a couple of occasions, Marten Gustafson has found himself in the midst of a project death march because his passion for the craft induced him to throw all of his time and energy into the project. Marten is not the first nor the last young programmer to throw himself into this bottomless pit with the good intention of heroically saving the day. If you are walking The Long Road to mastery, it is essential that you Nurture Your Passion for software craftsmanship while keeping it in balance with the other aspects of your life. Naturally, there will be times where the scales will tip in one direction or another. Nevertheless, you should be conscious of this balancing act all along The Long Road.

Action

Write down at least 15 things that motivate you. Wait a little while, then write down another five. How many of your motivations are about what other people think rather than what you feel? Are the percentages different between your first 15 and the final 5? How many of the motivating factors can you do without? Now write down a list of the five most important things that motivate you. Keep that list somewhere that you can look at it when times get tough.

Nurture Your Passion

To only a fraction of the human race does God give the privilege of earning one’s bread doing what one would have gladly pursued free, for passion. I am very thankful.

Frederick Brooks, The Mythical Man-Month

Context

You have been hired as “just” a software developer.

Problem

You work in an environment that stifles your passion for the craft.

Solution

Take steps to protect and grow your passion for software craftsmanship.

To become a journeyman, you will need to have a passion for software craftsmanship. 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.

Work on what you like. Find something at work that interests you, identify it as something you enjoy, and pour yourself into it. If you can’t spare enough time during the workday for this activity, consider putting in some extra time. If this isn’t feasible, dedicate some time outside of work to build some Breakable Toys.

In a presentation at O’Reilly’s Open Source Convention (OSCON) 2004 entitled Great Hackers, Paul Graham said, “The key to being a great hacker may be to work on what you like.... To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well.”

Seek out Kindred Spirits. Join a local user group that focuses on something you want to learn more about. Start a weblog and read blogs that interest you. Participate in online forums and mailing lists and Share What You Learn. Start a study group using the Knowledge Hydrant pattern language from Joshua Kerievsky’s paper “A Pattern Language for Study Groups.”[19]

Study the Classics. Immersing yourself in some of the great literature of our field can carry you through the rough spots when your passion is in jeopardy. These timeless books can open your eyes to a different world, a world where things can be better.

Draw Your Own Map. There are times when your needs, goals, and aspirations contradict the career paths your employer provides. Moving into an organization that offers career paths congruent with your own can protect your passion.

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.

Later in his OSCON presentation, Paul Graham went on to say, “Try to keep the sense of wonder about programming that you had at age 14. If you’re worried that your current job is rotting your brain, it probably is.”

Action

On your way to work prepare a list of three positive ideas to talk about. During the day, if the conversation starts to sap your energy, steer it to one of these three topics. The aim is to take control and avoid being dragged down by the negative conversations around you. On the way home, review your level of success and think about other ways to improve your environment.

Draw Your Own Map

Beware of the detractors. We might come across situations or colleagues or people in the society who will try to prove that programming...will become an unsustainable activity as time passes by. They think software development is only for fresh graduates...and when we get married and have kids we cannot do that anymore.

Mohan Radhakrishnan, comment [20]

Context

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

Problem

None of the career paths that your employer provides fits for you.

Solution

Identify a logical but ambitious next step for your career. Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up. Arriving at your next step and charting the course to ultimately arrive at your ideal destination is your responsibility. With your next career step identified, visualize the smaller, interim steps you need to take to move forward.

It is vitally important that you take the first step even if it doesn’t seem that significant. That first step will generate the momentum that will help carry you toward your goals. It’s the willingness to take that first terrifying step (and all the other steps later on), even in the absence of a perfect plan, that turns your map from a daydream into reality.

Rather than simply writing down high-level goals, try to define small, achievable steps. These small steps will provide feedback that you can use to modify your map, but they also make it easier to get help from Kindred Spirits to achieve your goals. After all, there’s not much anybody else can do to help you become what Paul Graham calls “a great hacker,” but they can point you toward resources that will help you learn Lisp or Unix socket programming or achieve similarly well-defined goals.

If you find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences, examine other opportunities to see if they’re heading in the desired direction. 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.

Use Sustainable Motivations and Use Your Title to prevent your current title and salary from narrowing the possible destinations on your map. If you need to move into a less hierarchically impressive role in order to stay “on the map,” consider The Long Road and compare the relative importance of impressive (short-term) titles and salaries to working in a company that is more congruent with your goals and will lead you greater heights in the long term.

These stories point to Desi and Chris’s priorities. They weren’t going to allow a company’s expectations or culture to stand in the way of achieving their goal of becoming a better programmer. These stories are particularly appropriate for system administrators and testing professionals who aspire to become developers. Too many organizations pigeonhole people and take a short-sighted approach to their personnel (or “resources”). Thinking of Desi as simply “a sysadmin” is easier to manage than realizing that Desi is a person who aspires to become a great programmer. 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.

Action

List three jobs that you think you could do following your current one. Then list three jobs each of those could lead to. Take a hard look at all 12 jobs. Is this really the full range of desirable jobs for the next few years of your life? Is there something missing? Extend this diagram by adding three jobs for each of the nine jobs you recently added. This should increase the number of jobs in your diagram by 27. Ask yourself if this set of jobs is more representative of the range of career options you have and the places you want to take your career. What are the constraints that are limiting your options?

If you’re unhappy with the diagram so far, repeat the exercise with different jobs, perhaps in different business or technology domains. Then try the exercise yet again and see what happens if you relax one of the constraints that you’ve always accepted. What if you become willing to move to another country, get a new qualification, or learn a new human/programming language? What if you were to start your own business? What if that business merely used software as a means to an end? There are more possibilities than you might think.

Use Your Title

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

Context

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

Problem

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.

Solution

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. They only serve to remind you that there is a shortage of craftsmen in our industry.

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.

Another variant of this theme is informal versus formal titles. For instance, you may have grown into a position of authority on your team, despite your formal title remaining the same. These informal titles can be hard to ignore, because they are constantly reinforced by your peers, even if they conflict with your self-assessment. During these times, your connections with your mentors and Kindred Spirits will be critical to keep you grounded in reality.

Action

Write down a long and descriptive version of your job title. Make sure it accurately reflects what you really do at work and your skill level. Keep this updated, and from time to time imagine how you would view a stranger who had this job description.

Stay in the Trenches

Seduced by the siren song of a consumerist, quick-fix society, we sometimes choose a course of action that brings only the illusion of accomplishment, the shadow of satisfaction.

George Leonard, Mastery

Context

As a result of your dedication to learning, you have established a reputation as someone who can effectively deliver software. Within your organization, exceptional work is rewarded with promotions up the hierarchy.

Problem

You have been offered a promotion into a role that will pull you away from programming.

Solution

The offer of a promotion will test whether you have Sustainable Motivations and are willing to walk The Long Road. Most people equate promotion into management with success. They assume that taking a promotion into management is a no-brainer, a sign that you are on the right path. Aspiring craftsmen must not be fooled into believing that they will remain a “technical manager” for long. As Pete McBreen wrote, “as soon as a person stops practicing, her mastery fades.” Every day that you are not programming is another step away from becoming a journeyman.

So to remain on that path, work with your employer to find other mechanisms for rewarding you. These may include more pay or nontraditional technical leadership roles such as internal consultancy. If your organization is inflexible, then it is better to seek opportunities elsewhere (see Draw Your Own Map) than to permit yourself to be promoted away from the craft.

Staying in the trenches is a way to Nurture Your Passion for software development. When you accept a promotion that allows you to continue programming full time, remember to Use Your Title.

It’s very easy to apply this pattern in a selfish way by being blind to the needs of those around you. However, as you become a more experienced apprentice you may find yourself trying to change your working environment so that others can keep doing what they love. This can easily become a full-time job unless you’re careful to maintain the balance or find ways to create a self-sustaining environment for increasingly senior programmers.

Action

How does your employer reward excellence? If their current rewards aren’t appealing, start thinking of other ways they could reward you. Consider whether there are standard constraints that could be loosened in your case. Perhaps there are restrictive clauses in your contract or you have a radical idea that needs sponsorship. Prepare a list of these alternative rewards so that when you reject that promotion, you’re in a position to negotiate based on a clear understanding of your own motivations.

A Different Road

Just because they’re not on your road doesn’t mean they’ve gotten lost.

H. Jackson Brown Jr., Life’s Little Instruction Book

Context

You have used Draw Your Own Map and followed it diligently.

Problem

The map you have drawn leads you away from The Long Road.

Solution

Follow your own map and remember what you learned during your apprenticeship.

You have been walking The Long Road for some time. But now as a consequence of Drawing Your Own Map you have realized that this road is no longer a suitable choice for you. You have found another path that has rewards more in tune with your current values: more time with your family or more money, or perhaps a new vocation has captured your attention. Whatever it is, it means saying goodbye to the craft and The Long Road. This may or may not be permanent.

Even if you leave the road permanently, the values and principles you have developed along the way will always be with you. As Dave found out when he ceased to be a family therapist, he couldn’t make Prospero’s choice (burning his books and breaking his staff), but instead brought the lessons and experiences from that vocation to his new craft. The same applies to you.

When we interviewed Ivan Moore, Ade’s mentor since ThoughtWorks, he described how he went off to a Greek island for six months to become a windsurfing instructor after his first IT job. He found that he liked teaching windsurfing, but it wasn’t entirely satisfying because he never got to use his brain. Afterward, it was hard for him to get back into the industry because “most HR people in big companies didn’t like it.”

We have colleagues who have left software development to become teachers, windsurfing instructors, and full-time parents. We respected their choices. If and when they came back, we welcomed them with open arms because those experiences had given them new perspectives they could share. Sadly, conventional software organizations may not be so welcoming. They often see these detours as suspicious gaps in your career that you must justify. They will expect you to have a rationale that makes sense within their value system for why you left and why you’re coming back.

Despite this risk, don’t be afraid to do something different with your life. If you walk away from software development, you will find that the habit of rigorous thinking and automating tasks involving large volumes of data will still be useful wherever you go. Your past as a software craftsman can enrich whatever future you choose.

Action

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.

Wrapping Up

The patterns that directly support an apprentice’s journey on The Long Road can be assembled into myriad combinations. Their ordering in this chapter does not imply a linear progression. For example...

You may be walking The Long Road with relative ease. Your working environment is not stifling you, your passion for the craft is strong. You are excelling. You receive a promotion to what your organization calls “architect” and you are still programming full time. Your Accurate Self-Assessment suggests that it’s time to Use Your Title to gauge the level of your organization. This may be enough to keep you on The Long Road, and perhaps no other patterns are needed.

...or...

Your organization emphasizes financial rewards. There is a constant, unspoken organizational undercurrent that pressures people to focus on making more money; after all, making more money implies you’re more valuable to the company. You recognize the undercurrent and the danger it presents to your journey. You Nurture Your Passion and focus on maintaining Sustainable Motivations. Your focus on Craft over Art has grown your reputation, and you are offered a promotion to project manager. By Staying in the Trenches and Drawing Your Own Map, you work with your employer to define a career path that will keep you on The Long Road.

...or...

You have been programming since you were very young. You program because you enjoy creating beautiful, elegant solutions. But now, in the corporate world, you are faced with tasks that are not enjoyable and with customers who need you to deliver functionality and who don’t care about elegance. You recognize that for the foreseeable future, your motivation for programming is not aligned with The Long Road. You take steps to Nurture Your Passion as you develop more Sustainable Motivations by focusing on Craft over Art. Over time, you gradually develop a motivation to establish strong relationships with your customers.

As you can see, the possibilities for combining these patterns are as limitless as the contexts that apprentices live within.



[15] John Littler, “Art and Computer Programming.” Available at: http://www.onlamp.com/pub/a/onlamp/2005/06/30/artofprog.html.

[16] Laurent Bossavit, personal communication.