This post is in response to http://terrychay.com/blog/article/challenges-and-choices.shtml, specifically this part:

When people put "design patterns" on their resume, I like to ask them a particular question -- especially when their background is J2EE or they say they know design patterns. The question I like to ask is define design patterns -- what does that term mean? I’d say about 90% of the people who put that on their resume bomb that question. It’s actually not an easy question. As soon as they answer it -- they give me some sort of pseudo-book definition -- I tear into them. I’ll give you an example:

The typical thing that they’ll say is, "Oh! A design pattern is this code thing that solves...umm...a problem."

And I’ll go, "Well, shit." laughter "Quicksort, right? That must be a fucking design pattern then." laughter

And then they’ll say, "Well no. Quicksort isn’t a design pattern."

Then I’m like, "Well, explain to me how it isn’t a design pattern. Your definition is that is solves a problem -- which I agree, design patterns do solve a problem -- but obviously that’s not a sufficient definition for design patterns."

You get where I’m coming from? And the reason isn’t...

And then they’ll say something like, "Well, you know. It doesn’t have like... It’s not an algorithm!"

"Umm...Yeah. So then design problems are something that solves a problem but isn’t an algorithm. So, code versioning! The practice of code versioning solves a problem and it’s not an algorithm clearly! (In fact this is what’s called a "best practice.") So how is a best practice not a design pattern?"

See no matter what they do they fall in a fucking trap. laughter

So I’ll give you my definition of design patterns. Well my honest-to-goodness definition of design patterns is to quote a famous Supreme Court justice when he was talking about it: He said that he’ll know it when he sees it.

Actually, he was talking about porn. laughter But there is pretty much no difference between design patterns and porn so we are all okay with that.

For Terry to say "design patterns are like porn, you know it when you see it" is funny and entertaining, but careless and unhelpful.

When a web developer talks about design patterns, it seems likely he means patterns of the type described by Martin Fowler in "Patterns of Enterprise Application Architecture". Regarding the definition of patterns, Fowler has this to say on page 9:

There's no generally accepted definition of a pattern, but perhaps the best place to start is Christopher Alexander ... "Each pattern describes a problem which occurs over and over again in out environment, and then describes the core of the solution to that problem, in such a way that you can use this soution a miillion times over, without ever doing it the same way twice."

Fowler then goes on for several paragraphs refining and explaining the concept. So while nobody has a rigourous definition of "design patterns", there does appear to be a rough outline of how to discover them, and then to agree on instances of patterns by naming and describing them. (Whereas the definition of porn cannot ever be agreed on, becuase it is in the eye of the beholder. I'd prefer not to take the analogy much further. ;-)

Patterns as Domain-Specific Vocabulary

Fowler (page 11) says "... the value of the pattern is not that it gives you a new idea; the value lies in helping you communicate your idea." That is, patterns are a common vocabulary to aid communication. Application design patterns are a vocabulary to aid communication about application design.

There are many kinds of patterns in the software world. To use Terry's examples, quicksort could easily be called a pattern of some kind, perhaps a sorting pattern. Code versioning could also be called a pattern of some kind, perhaps an organizing pattern. Best practices might be patterns of management. But they're not application design patterns.

Intellectual Bullying

As the interviewer, Terry does not appear to be seeking to tease out what the applicant thinks he means when he says "design patterns". Terry uses the term "design patterns" in a generic way, instead of in the way the applicant most likely intends -- "application design patterns". It sounds like Terry is attempting to trap the interviewee by subtly and purposely misleading him.

I have to wonder if that kind of questioning technique is appropriate behavior for someone in a position of power (and the interviewer does have a measure of power over the applicant). It sounds like an intentionally negative experience, one that is unnecessarily humiliating.

In fact, it sounds like bullying; intellectual bullying, to be sure, but bullying nonetheless. It reminds me of passages from the chapter on "Homo Logicus" in Alan Cooper's "The Inmates Are Running The Asylum". Cooper (101-104) compares and contrasts the physical/athletic jock and the mental/intellectual jock, both of whom exhibit immature bullying behavior.

The athlete bully, with great physical prowess, begins with the idea that "If I can beat you in a physical contest, then I am your master and I am better than you," but eventually is conditioned to accept that physical domination is not socially acceptable. He grows up when he realizes he can't get along with other adults by bullying them.

The intellectual bully, with great mental prowess, begins with the idea that "If I can beat you in a mental contest, then I am your master and I am better than you." However, the intellectual bully rarely learns that mental domination is similarly unacceptable in civil, adult discourse. "There is no maturation process to temper their exercise of that power." (Cooper, 104)

Closing Thought

When in a competition, physical or mental, try to win! But civil discourse is not competitive; you don't "win" a conversation. Mature adults attempt to work with each other to clarify meaning; they are both truthful and helpful when speaking to each other. They try to "find out what is right." Bullies and the immature, on the other hand, want to "be right" period, even if (maybe even because) that means knocking the other person around. Beware the mental bully in yourself, and point it out when you see it in others.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving you codebase, all while keeping it running the whole time.