Patterns

“Design Patterns” is a terrible term. Mostly because of the baggage and connotations attached to it.

So lets drop it, reduce and cut down to the crux of the matter; patterns. Just patterns. But only the part that relates to software. Because that is the part that I am interested in.

I have struggled for some time to come up with the right analogy, the right explanation, for how I see patterns. And I think a big part of the puzzle finally fell into place today:

In what language does a good composer think, when he composes? In what language does a good programmer think, when he programs?

Not notes, and not codes. Those are too low-level. Those are interned. They bend naturally, sometimes even effortlessly, to his higher-level thinking.

He thinks in a pattern language. Perhaps not consciously, perhaps he calls it something else. But it is the level of abstraction at which his mind works.

The mind hates to work slowly or inefficiently. Especially if it is a kind of work that it has to do often. Working with bigger pieces – patterns – instead of smaller bits, facilitates efficient thinking.

If his mind does not work with patterns, then I see two possible causes: He has not yet attained a sufficient level of skill to recognize the patterns, or how they fit together; or he has transcended the patterns, and probably gone from good to great in the process.

Given this, you can say that programming is like composing music that express logic instead of feelings.