This book is dedicated to the clients and students at all my consultancy gigs for being open-minded; to the ThoughtWorkers for the good times and the bad times; to the other TSEs for being Googley; and to my friends and family for loving me anyway, even though they didnt always understand.Ade
Twenty-five years ago Kent Beck and I sat in Tektronixs Technical Center cafeteria wondering what impact our privileged access to Smalltalk-80 would have on the world.
Never mind reality, I advised Kent. If we could do anything, what would we do with this knowledge?
I want to change the way people think about programming, Kent said. I agreed. We both wanted to reverse what we thought had been a wrong turn in the progress of our industry. And, amazingly, we did it.
That device I used back in the cafeteriathe never mind reality partwas a pattern that Id first observed used by my college advisor. He tried it on me just like I used it on Kent. The activity, which I now recognize as a pattern, helped Kent and me dare to imagine far-off goals that might otherwise have seemed audacious. And once imagined, our goals looked more achievable.
I call the thought device a pattern because it solves a problem that we often have: we censor our own ambitions. This book is full of similar devices for a wide range of problems. We say that patterns solve problems. Never mind reality solved a problem for Kent and me. It got us thinking big thoughts that stuck with us and let us push through our habitual self-censorship.
Youve probably tried the never mind reality pattern yourself. If you havent, give it a try. The strongest patterns are the ones that are applied productively over and over again. Patterns dont have to be new to be useful. In fact, its better if they are not new. Just knowing the names for established patterns is a big help too. Identifying a pattern lets you discuss it without having to retell the whole story every time.
Leaf through this book. Youll see lots of patterns. Many will be familiar. For any one you might say, I already have that patternand you probably do. But there are two ways that the written patterns here can help you, even when the solution is common knowledge.
First, the written pattern is more complete. It has been studied, characterized, classified, and explained. Youll find unexpected nuggets in each pattern. Savor these nuggets. They make the patterns you already have more powerful.
Second, the patterns are connected. Each one leads to more. When you find one that you already know, you can follow these connections to other patterns you may not know, or never thought of as working together.
Kent and I mined Smalltalk-80 for patterns, and we found plenty. We pitched the pattern concept to our peers, and launched a small revolution. We changed the way people think about programming. Many dozens of books have since been written about patterns and how to use them.
Our revolution is hardly over. The piecemeal growth of pattern terminology became a foundation for Agile software development methods. Many more dozens of books have subsequently appeared.
So, why this book now? Well, weve overloaded our profession with resources. There is more information available about our revolution than any one person can absorb. Still, some people manage to do it. They internalize all the advice available to them and always seem to have it close at hand. How do they do achieve that level of mastery?
This book is full of patterns for mastering our complex field. Mastering is more than just knowing. It is knowing in a way that lightens your load.
Let me give you an example. If you cant remember the order of arguments to the SUBSTR function, you can look that up on the Internet. Thank goodness for the Internet. It has lightened our load a little. But when you use this books patterns, when you approach your work always open to improvement, you will find yourself writing a different kind of code, code that doesnt depend on knowing the order of SUBSTRs arguments. You will write programs that soar far beyond SUBSTR. This will lighten your load a lot.
All the advice that has come out of our revolution does not help much until it becomes second nature. The craftsmanship movement in software recognizes that making this stuff second nature isnt, well, second nature. These patterns are a welcome contribution to this progression.
Preface
He who knows not and knows not that he knows not, is a fool shun him!
He who knows not and knows that he knows not, is unlearned teach him!
He who knows and knows not that he knows, is asleep awaken him!
He who knows and knows that he knows, is enlightened follow him!
Arab proverb quoted by Lady Isabel Burton (18311896) in The Life of Captain Sir Richard F. Burton
Goals
We have written this book in order to share solutions to the dilemmas that are often faced by inexperienced software developers. Were not referring to technical dilemmas; youre not going to find any Java design patterns or Ruby on Rails recipes in this book. Rather, the dilemmas that we focus on are more personal, concerning your motivation and morale. This book should help you through the tough decisions that you face as a newcomer to the field of professional software development.
Audience
This book is written for the person who has had a taste of software development and aspires to become a great software developer. You may be a web developer or a medical device programmer, or you may be building trading applications for a financial institution. Or perhaps you have just graduated from high school or college knowing that software is your future.
Although this book was written for newcomers, more experienced developers will benefit from its content as well. People with several years of experience may find themselves nodding their heads in recognition of dilemmas theyve already faced, and may come away with new insights or at least a new vocabulary to describe the solutions they want to apply for themselves or suggest to their colleagues. Even people with a decade or more of experienceparticularly those who may be struggling to navigate their careerswill find inspiration and perspective to counter the siren call of promotion to management.
Process
The idea for this book was first hatched when Stickyminds.com asked Dave to write a column about Software Craftsmanship in early 2005. Since Dave considered himself an (experienced) apprentice at the time, the only topic he felt comfortable writing about was apprenticeship. This got him thinking about what he would want to write on the topic. Around that time, Dave read a blog post by software developer Chris ] to a private wiki that Dave used to organize the initial patterns. The initial patterns were extracted from Daves career up to that point (20002005).
Understanding that these so-called patterns could not really be called patterns unless they were actually common solutions to common problems, Dave began seeking feedback from colleagues in three forms. First, he began publishing the patterns publicly on his website, soliciting feedback with public comment forms. Second, he began interviewing (mostly via email) thought leaders in the field of software development and getting their opinions on the initial patterns. Third, and most important, Dave began interviewing less-experienced practitioners to test the patterns against their recent experiences. The stories told by the less-experienced practitioners also introduced Dave to new patterns that he hadnt yet encountered, or hadnt recognized in his own experiences. It was during these apprenticeship interviews that Dave interviewed Ade, and by mutual agreement, Ade joined the project as a coauthor.