I'm Sick Of GOF Design Patterns

In the famous 1994 book "Design Patterns: Elements of Reusable Object-Oriented Software" the authors covered a number of classic object-oriented design patterns in addition to covering some basic design concepts. It's a nice book in some ways.

But what people have done with it is beyond tiring. It's not the be all and end all of how to write software. It's not a recipe book to be followed slavishly like some kind of paint by number template.

People always ask if you know design patterns in interviews. Job descriptions list "familiarity with design patterns" like it is some kind of secret knowledge only real programmers know. Instead of a book with some useful concepts you might read once, it became the Programmer's Bible to be paraded around like Chairman Mao's Little Red Book.

Anyone who has ever been a programmer over any length of time will accumulate "patterns": things you did in the past that worked, ideas you got from coworkers or online or from a book, basically anything that was worth remembering that seemed to be useful. Everyone's experience is different but it makes up the toolbox you use in your daily work. Your approach to solving problems, how you test or debug, how you think about structure and design, your personal process; all sorts of things make up your "pattern". These are what you offer to an employer, however fuzzy they may be.

Yet people insist on you naming a design pattern in interviews, like it's a secret handshake,  or asking a carpenter if they know any kinds of wood. What does it prove? Nothing.

Programming is not coding by numbers or simply cobbling known patterns together. Today I will write a flyweight pattern and then add some strategy and maybe a proxy which goes well with a nice Chianti and some Fava beans.

I remember when J2EE came out in the late 1990s. One of the concepts Sun pushed was that the future of programming was stringing together EJB's you found in a directory somewhere. Of course it never happened, the idea was pretty ludicrous. But programming by patterns isn't much better. My toolbox has more than screwdrivers.

Mozart composed music in the style of the period he lived in, he knew what people expected, he understand how to craft excellent music that people would want to listen to, and he certainly knew all the things only bad composers did. He did not write music by filling in blanks in some preconceived template even if the music of the time was highly formulaic: he created music people still listen to today because his patterns were all internalized and he knew how to compose within, and also violate, those formulas without resorting to stringing together simplistic bits of music. He knew all the mundane basics but that didn't drive his compositions.

Programming likewise isn't a bag into which you pour some things you read in a blog. It is an aggregation of your experiences, successes and failures, experiments and deliveries. Like any craft  you discover things that work, ideas that have merit, and yes patterns that are worth reusing.

Looking at a set of canned design patterns as something independent and meaningful in all situations isn't craft, it is paint by numbers. It is a tool like anything else. Programming isn't paint by number, every day you make decisions on what to write and how to design or structure the code in a continuous basis. The set of patterns from the book are a useful collection but knowing what they are isn't by itself any indication of what you can do.

Given that languages today are often functional or hybrid types, the GOF patterns may be entirely irrelevant for many people. Today having a broader knowledge of how to use these types of languages and being willing to learn how to use them effectively is way more useful than remembering a static set of anything. Programming these days is constantly changing, and anything written twenty years ago may be partially or even completely pointless today.

So stop asking if people can name a design pattern. Everyone replies "Singleton" anyway!