Patterns of Intellectual Bullies

By | November 7, 2008

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.

17 thoughts on “Patterns of Intellectual Bullies

  1. Jacob Santos

    Often, I try to define a complex solution around a problem to answer the question of extensibility and re-usability. Design Patterns help facilitate the correct solution by means of bridging the gaps in my lack of experience. Eventually, I’ll find the best solution at some point, however going off a predefined set of design patterns, I can come to the best answer sooner rather than later and be better coder because of it.

    Coding isn’t a competition and learning from the heartaches, pain and suffering of others and gaining their insights serves me in that it allows me to better do my job.

    I’ve never interviewed with Terry Chay, but I think both of you have a higher intelligent than I could ever muster. I wish you would give more insights such as these, but without the finger pointing. Very much enjoyed this post.

    Reply
  2. Bill Karwin

    I fully agree. It reminds me of an interview I had in 2002. “What’s the difference between C++ and Java?” I was asked by the engineering manager.

    “Well, they’re certainly similar, both being strongly-typed object-oriented languages (more or less). They both compile to lower-level bytecode, but in Java’s case this is an abstracted bytecode that runs in a virtual machine, so Java necessarily includes a runtime component, whereas C++ typically doesn’t. C++ is an ANSI standard, but Java is an industry specification from Sun. Java has built-in garbage collection…”

    “WRONG!” he roared. “There’s NO difference between the two languages, they’re identical!” Then he leaned back smugly and pretty much didn’t ask any more questions.

    I still wonder why he bothered to ask me the question. What did he learn about me from my answer?

    That’s the problem with “booby-trap” interview questions. If you have already decided that the candidate can’t answer the question to your satisfaction, then there’s no chance of gaining any information by asking it.

    Reply
  3. Joe

    funny, i’d never heard of chay but stumbled upon a few posts he made about ruby on rails whilst researching the value of ror vs php. i found his posts fit very much into the “intellectual bully” category. he was more concerned with “being right” as you put it, with fairly basic arguments actually “the top 10 companies use X, therefore X is right”. although he makes some valid points, it takes some amount of sighing on the part of the reader to get there. he is very unhelpful to the novice. i agree with the previous poster, coding is not a competition. we want to solve problems with the right solutions. there are many solutions to a given problem, much as that would break chay’s heart. design patterns are a useful abstraction and discussion of a problem, allowing for many solutions but validating the repetitive problem at hand. my reply has turned into a mess, much like most of my posts, but i hope there are some valid points here.

    Reply
  4. Nick

    I can’t agree more, especially in the context of interviews. Ideally no interview question is worthwhile unless the process of arriving at an answer is held to more importance than the actual answer. That’s a difficult, maybe impossible, standard to adhere to 100% of the time, but I know that there are plenty of people out there like you, Bill (this I know from being interviewed by you), and I hope myself, who aim for it in their process.

    Reply
  5. Martin

    He’s not trying to mislead the interviewed, he’s asking him to clarify what he means, often people put buzz words on their résumé without actually knowing what the term means. He’s not telling the interviewee person he’s wrong, he’s merely trying to get the person to think for himself, personally I wouldn’t want to hire someone who was a text-book programmer. Programming isn’t something you learn in college, it’s something you learn through doing and while the kind of questioning he was doing might put the programmer on the spot it would also show if he was capable of actually thinking or if he was just reciting what his lecturer told him. In a world that’s ever evolving, often quite a bit between versions or from week to week, can you then really afford to hire a person who can’t think for himself?

    Reply
  6. Pádraic Brady

    I think Terry’s personality hides its true intent. Most interviewees will fall at the hurdle because they don’t have a clue, some because the high pressure of an interview has a habit of leaving one’s memory blank for several frantic seconds ;). The f-bombs would be more worrying – I don’t see nerves vanishing when the interviewer is constantly pumping those out!

    I will say the questions are leading interviewees down the garden path and beyond. The answer Terry seeks actually is the textbook answer if you condense pages of text into several short attributes. The flipside is that it’s so condensed it tells you little about the interviewee’s actual knowledge. I’d be more inclined to prompt a design pattern name and ask them to discuss it. A good example is more likely to expose knowledge than seeking definitions…

    Reply
  7. Lars Strojny

    Strange enough the applicant couldn’t answer the question straight away like “design patterns are repeatable solutions for problems in software architecture”. And we should be pretty silent when it comes to incomplete definitions. I mean nobody has found a good term for the strange thing between software architecture and raw syntax. Implementation? You kidding me.

    Reply
  8. Ilia Jerebtsov

    I think the real issue here is that if you’re going to put down “design patterns” as a point in your resume, you might as well write down that you know how to make conditionals and loops in your codes. Application design patterns are just names for things you commonly do in code. They’re just as much part of the natural programming process as the “if-else” for any serious programmer.

    Bringing it up in your resume just looks like a blatant attempt to use something you don’t understand to make yourself look more knowledgeable than you really are. Bursting that façade is always amusing.

    Reply
  9. Pingback: The Woodwork » Blog Archive » Defining Design Patterns

  10. Pingback: The Woodwork » Blog Archive » Terry the bully

  11. terry chay

    @Pádraic Brady: After the definition question, I decide to continue with

    “Name a pattern?”
    “Tell me how you would implement that in PHP?”
    “Tell me what problem does that pattern solve?”
    “Tell me what are the consequences of that pattern?”

    You can see that it’d be hard to ask that battery if we haven’t even established that design patterns must have a name, must solve a problem, must be implementation independent and must have consequences. ;-)

    Typically…

    Name a pattern? Singleton
    How do you implement it? (If their resumé says PHP 4, they can get into trouble here as you well know)
    What problem does it solve? It ensures there’s only one of them. (This is not quite correct as the next question shows)
    Hmm, sounds like a global variable. Tell me, when would I use a global instead of a singleton and vice versa? …

    Reply
  12. Dave

    Terry makes the point that the candidate must think through the meaning of “design pattern”, not simply pedantically rat off some quote from Fowler. Design patterns themselves are a good way for poor programmers to feel intelligent. I work with PhDs every day. We’re working on some complicated systems. Not once has anyone mentioned a design pattern. It’s beneath us to get excited about a bunch of vocabulary.

    Reply
  13. Anon

    A pattern: Front Controller

    Implementation: index.php routes the request and includes the necessary parts (.htaccess can help out)

    Problems that it solves:
    <php include ‘header.php'; >
    Page content
    <php include ‘footer.php'; >
    on every page, to name one. DRY.

    Consequences: No infrastructure will be in place to add scripts that behave independently, unless you include the resources the same as does the front controller. Rasmus hates you.

    Nobody’s hiring for PHP out here though.

    Reply
  14. Pingback: Ivo's Blog - jansch.nl » Blog Archive » Why did the chicken cross the road?

  15. Pingback: php-Phreaks » Blog Archive » Why did the chicken cross the road? - Ivo Jansch

  16. Les

    > A good example is more likely to expose knowledge than seeking definitions…

    You miss the point entirely. If you are unable to explain in a sensible and deliberate manner what a design pattern is and the purpose for using a design pattern then it negates what ever level of knowledge you have.

    In a team environment we talk about design patterns day in and day out, and we more or less know what we are talking about when some one mentions ‘Decorator’ for example?

    To me, it’s not about code implementation, as implementation is different from one context to another, from one platform to another, what it is about though is communication.

    If someone lacks a complete and full understanding of design patterns then that communication breaks down.

    Reply
  17. D

    Man, this article couldn’t be more right on the money and this industry is most definitely full of bullies. I mean just look at some of the comments for this very article! People just can’t help themselves. Any chance to make yourself feel better by making someone else feel worse. Pretty sad.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *