Chapter 3. Walking the Long Road
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
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.
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.
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.
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.
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.
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.
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.” 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.
Ken on craftsmanship
Working on real problems for real people is what hones the craft, not just doing it for self-satisfaction.
|--Ken Auer, email|
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.” 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.
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.
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.
As an apprentice, you must develop your technical skills. Because of this you will often find yourself working in the messy realities of ambiguously specified projects for customers with shifting and conflicting demands.
Working in the trenches of real-world projects is rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining.
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.
...there is not much overlap between the kind of software that makes money and the kind of software that’s interesting to write.... If you want to make money, you tend to be forced to work on problems that are too nasty for anyone to solve for free.
|--Paul Graham, Hackers & Painters|
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.
Dave’s low pain threshold
During the evolution of this pattern, David Wood (one of my Kindred Spirits from my ThoughtWorks days) shared some conventional wisdom with me: “Do what you love and the money will follow.” This advice resonates with me because I am a complete wuss when I can’t do what I love. On the flip side, when I’m doing what I love, I find that I have an overwhelming amount of creativity and energy to throw into my work, which ultimately provides me with greater financial rewards. While many programmers could probably find higher-paying jobs in the short term, the money that follows from doing what you love will pay off handsomely in the long run. To read more about this unconventional wisdom, check out the commencement address to Stanford’s class of 2005 by none other than (college dropout and Apple cofounder) Steve Jobs.
|--David H. Hoover|
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
You have been hired as “just” a software developer.
You work in an environment that stifles your passion for the craft.
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.”
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.”
The traveler whose main path of mastery coincides with career and livelihood is fortunate; others must find space and time outside regular working hours for a preferred practice that brings mastery but not a living wage.
|--George Leonard, Mastery, p. 133|
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.
None of the career paths that your employer provides fits for you.
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.
Desi draws her own map
I took a job working at a startup company doing all sorts of things including database management, system administration, quality assurance, source control, and even some project management. The role changed over the years and after a while I started to feel the itch to try my hand at programming again. I started out with SQL scripts, Perl scripts, and some shell scripting. These scripts revolved around all of the other duties I mentioned above. I realized that programming was actually fun when you had the time to spend in learning what you were doing and didn’t have the pressures of an actual class. I was happy with this for a while but the pressure from my boss on me to become more systems-oriented started to conflict with my desire to move into development. I lost motivation for programming because my job demanded other types of learning and work. I was frustrated because it was not the work I wanted to be doing but I felt that I had managed to get myself stuck. I wanted to leave production operations and system administration behind or at least only do it as a side effect of writing code but the company I was working for would not allow me to make that move. I was having a difficult time finding a job as a developer due to the fact that I had been out of school for 4 years but had no real programming experience. I left the company and went to another company and continued in a configuration management role. I started to try to introduce Perl to this new company and I was met with a very large resistance. I realized that I would have to make another move because my desire to write code was getting stronger. Fortunately ThoughtWorks decided to take a chance on me.
|--Desi McAdam, email|
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.
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.
Your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description.
Do not allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness. Use your title to gauge your organization, not yourself.
Don’t be fooled by an impressive title. Your mother might think you deserve it, but impressive titles and responsibilities do not indicate that your apprenticeship is over. 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.
Dave sees the sign
Two years after I wrote my first program, a Perl CGI script, my title was “Senior Application Developer.” Having developed a fairly accurate self-assessment, I saw the humor in my situation. Rather than believing that I had achieved my goals, I saw this title as a sign that I needed to move on, to Draw My Own Map.
|--David H. Hoover|
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
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.
You have been offered a promotion into a role that will pull you away from programming.
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.
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.
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.
You have used Draw Your Own Map and followed it diligently.
The map you have drawn leads you away from The Long Road.
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.
Larry’s detour through family therapy
In a sense, I can’t stay away from the people issues any more than I can stay away from computers. I thought I had escaped when I bid farewell to the computer field in July of 1976, declaring my independence even as America celebrated the bicentennial of its independence. Trained as a family therapist, I ended up spending more than a decade in private practice and agency practice working with couples and families and troubled adolescents. But the forces of the universe conspired to steer me back toward the technological frontier.
|--Larry Constantine, The Peopleware Papers|
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.
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.
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.
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.
 John Littler, “Art and Computer Programming.” Available at: http://www.onlamp.com/pub/a/onlamp/2005/06/30/artofprog.html.
 Laurent Bossavit, personal communication.
 http://apprenticeship.oreilly.com/wiki/show/draw_your_own_map (must register and log in)