Comment by klync | Hacker News Reader

Comment by klync | Hacker News Reader

I wasn't sure whether to upvote this article, until I got to this line:

> Design patterns are a universal language that few people speak, a sort of Esperanto for programmers.

Exactly. And I fully expect many of the hackers here to chime in with 'oh, that article is so wrong'. But, the thing is, HN geeks, you are that rare breed that knows and applies the patterns. I've met you, and I've worked with you. And for every one of you I've met in my career, I've met 200 who couldn't give a damn what a DTD is, let alone a pattern.

Design patterns are actually an excellent concept, but they won't really help programming for the masses. And, the more we depend on computing in our lives, the more we need programming as a technical discipline to be able to accomodate the masses. For every structural engineer out there in the real world there are probably a thousand architects. And for every architect, ten thousand carpenters. I know an expert carpenter and I'm pretty sure he couldn't calculate the tensile strength of a basswood 2x4, but he can sure build me a deck!

This article is complete garbage, and I'll tell you why. Being a competent programmer is about being good with logic, constructing a detailed mental model of a system in detail, and thinking across multiple abstraction layers. The problem is there is no litmus test for this. You can glean something from clever interview questions, or coding tests, but even other programmers won't know for sure until the person cranks out code for a while. The problem with using design pattern knowledge as some sort of test is that it's too high level. It's just some observations about things that tend to work in certain situations. But anyone can read about them and if they are moderately intelligent they can talk the talk even if they can't code their way out of a paper box.

My other problem with this article is that the author starts off sounds like he almost understands a bit about programming, but then he veers off unforgivably about the divine superiority of design patterns. "They are worked out for you and bestowed from on high by geniuses so much smarter than you that they solved all problems at once better than you will ever solve your specific problem, and therefore your code will automatically be better if you use them, and suck if you don't!" That's a ridiculous overstatement at best. Knowing design patterns is better than not knowing them, but only if you have the chops to apply them properly. If you don't then you may just be adding complexity without solving anything. Furthermore, design patterns are actually just an emergent property of working systems; just because you don't know what they're called doesn't mean you're not using them. To work with code, such as to make bug fixes, or to extend it you need to go to a much finer level of detail, and to make a large scale system you need to think about overall data flows that are far higher level than the design patterns used in individual components.

Design patterns are to programming as literary devices (allegory, simile, onomatopoeia) are to writing. If someone knows them you can tell they have studied literature, but it doesn't mean they can write worth a damn.

The article doesn't argue that knowledge of design patterns is what defines someone as a good programmer. It's just pointing out that very few programmers know enough about design patterns to be able to recognise the problems that they are intended to solve.

If someone knows what design patterns are then that's one piece of information to find out about them during interview and add to the overall picture of them.

I do agree that there is alot more to finding out if someone is a good programmer that one aspect such as design patterns.

Counterpoints to what you are saying:

Actually the okay but not so good programmers are more likely to be hung up on design patterns. They have learned few of them, and try to apply wherever they can, even when they really shouldn't. Aslo people that tend to do over-engineer a lot tend to overuse design patterns. Also you will see them in interviewees asking a lot more about design patterns themselves than actually coding/problem solving ability. It is is just a higher end version of asking "programming trivia".

To the risk of being downvoted, I repeat again: overuse of design patterns is a hallmark of mediocre programmers, or programmer that are not very experienced yet (they may become really good one day, but not there yet).

Yeah, I agree with your overall point. In general, a sign of mediocrity in any field is someone who over-uses jargon in any field. As much as I hear people throw around "design pattern" terminology, I also see overkill on the now-en-vogue topic of "useability", with phrases such as "use case" being applied at any and every possible opportunity.

In fact, though, what has proven my comment wrong is that the HN community has not chimed in as I predicted. This is a(nother) really informative and thoughtful conversation... I love it here! :D

Cargo cult programmers are dangerous no matter whether they've been reading horrendous code or excellent code. If you try to build an airplane by copying a beautiful mansion you will still fail.

Agree. Actually design patterns are really good to apply at refactoring time. You often cannot foresee what problems you will be facing and how your code will evolve in order to start trying to stuff in all the patterns you are familiar with. Write code -> see a problem -> identify a possible pattern -> refactor accordingly. This is also learning design patterns by doing.

I've found that Anti-Patterns (http://en.wikipedia.org/wiki/Anti-pattern) are the best approach for refactoring. They explicitly start with recognizing a bad pattern (frequently one which once made sense but no longer does) and then explicitly prescribe methods to refactor them into something better.

Reply on news.ycombinator.com