Dave Hoover - Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

For Staci: my best friend, my wife, an Ironman, and mother of our children.Dave

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.