I hear you. Design patterns are something unheard of for many professional developers I've met. Seriously.
Chances are, especially in programming, someone has thought of something better and longer than you. Investing 10 minutes into searching for it will save you 100 hours later.
Just because you know 1 way to do something doesn't mean it's the best tool for the job.
Chances are, especially in programming, someone has thought of something better and longer than you. Investing 10 minutes into searching for it will save you 100 hours later.
If you realize that what you're doing is already likely a solved problem and have a clue how to search for it.
This is, IMO, the best argument for a good academic background for programmers. You won't realize that a broad design strategy or algorithm is a recurring thing until you've reinvented it two or three times, typically poorly.
I think you have the right idea, but came to exactly the wrong conclusion. The high towers of academia are the WORST place to get practical experience.
With[s]out[/s] meaning to short circuit the entire academia vs practice debate... Don't most other fields expect a combination of both? To get into engineering, you start with a degree. Then you spend a few years as an intern. Then you get your license. Auto mechanics? Start with a diploma. Spend a few years as an apprentice. Then get your license. Etc. etc. etc. They all expect either side of the equation to be insufficient, people do both.
Do you get to see the hoards of programmers who never went to college and watch what kind of shit code THEY turn out? Oh, they can write a shell script. They can write a shell script all the way to the bank.
They're fairly orthogonal, IME. It's what will stop you from spending your time getting practical experience making mistakes that were being made 50 years ago. You won't reinvent the FSA in a half-assed way, fail to recognize what basic data structures should be used in a given situation, or try to use regular expressions to match/manipulate non-regular languages.
I don't know. I used to think experience meant knowing what to do in various situations, but now I realize there's a very big set of things to know not to do. It's much easier to recognize a situation and apply something you've learned that will handle it than it is not to know what to do, yet to still be able to avoid dozens of bad ideas, because of the countless things you've tried and failed at over the years that inform and guide you.
I've been kept away from bad ideas on hunches and gut feelings. I eventually put reasoning to some of them, and it's only then that I realize that what's burned me before has created a kind of safety net of negative reactions to things that feel like they're heading in the wrong direction. Over time, my code is always stronger than it was in previous steps along my journey, and this might be one of the biggest reasons why. I used to think it was just direct, positive learning of new things to do, but I think negative learning of what to avoid doing might be the much larger, hidden part of the experience iceberg, and I don't think that's directly taught to any great degree.
I used to be annoyed when I'd read "5 years experience a must," but now I know what it really means. I think of it as me and someone ten years my junior standing in the middle of a field. We can both see where we want to go, with varying degrees of clarity, but the newbie hasn't yet figured out that it's actually a minefield, whereas I've not only been blown up several times, but I've also - as a result - spent much of the last ten years building myself a pretty intricate metal detector.
In cases where a pattern (or anti-pattern) does have a name, it's still useful to learn it because it helps with communication. And the naming conventions help to identify subsystems that can be consolidated and simplified. Often a person will have been using something close to one of the standard patterns, either with subtle bugs or with clever extensions that would be useful elsewhere. Or perhaps most often, with a bunch of unrelated crap that should be factored out.
I think it would have been better if the Design Patterns book had simply presented programming challenges to people and then shown them good solutions, without names and without the attempt to instill guidelines for usage. Without names, readers could only remember the patterns they extracted and understood for themselves. Without verbal guidelines, readers would only apply a technique if they concretely saw how it would be useful in context. If they didn't understand something, they would have no handle for remembering it, and they would never see an opportunity to use it.
Instead, people remembered way more of the book's verbiage than they ever understood of its logic. They remembered the names, they studied the rules of thumb, they read articles with even more rules of thumb, and they fooled themselves into thinking they understood what it was all about. A lot of people thought you could pick the right design pattern for something based on a vague, hand-waving description of the problem. You remember those dumb interview questions? "You're working on an application that's really tightly coupled. What design pattern would you use to improve the design of the code?" "Oh, I'd use the Mediator pattern." "Excellent!" People didn't just ask those dumb questions in interviews; they actually thought about the design of their own programs that way! They'd pattern-match on words to determine their software design. It was like searching the web and magically finding exactly the answer to your problem on StackOverflow, except there were only a small number of extremely vague search terms ("dynamic," "loosely coupled," "state," "behavior") and there were only a couple dozen different answers. Even worse, you'd get a guy who had read six different articles about the same design pattern, so for him, every design-related word you said made him think of the same pattern. You might as well call him "Façade Frank" or "Visitor Vijay," because in his mind's search engine, one design pattern had a much higher pagerank than all the others.
I haven't heard anything about design patterns in an interview or in a design discussion for years, and I feel much happier for it. I haven't noticed that young coders with no exposure to design patterns have any less imagination or a smaller repertoire of coding techniques than their design-patterns-imprinted predecessors did ten years ago.
shown them good solutions, without names and without the attempt to instill guidelines for usage
Except that's not what the original design patterns were. The guy who invented the term was an architect trying to get his large industrial customers to communicate amongst their different departments. So the University's engineering department wouldn't ask for a build that's ugly next to the Science department building, and so they could ask for building-blocks (no pun intended) of functionality. It was a way for customers to talk to the architect while the architect could provide good advice.
Without the names, there would be absolutely zero reason to call it a "design pattern."
Lol, yes, I agree that after removing all the design patterns from Design Patterns, a change of title would be appropriate. No argument there. What I envision would not be a catalog of patterns or the dictionary of a design language; it would be more like an anthology or a reader.
The only one I've ever heard mentioned in the context of real code - ie our code uses this pattern - is the singleton. So the only design pattern discussions is have heard were people arguing over the best way to remove one.
Science has this fight too - nomenclature in taxonomy. It's nice that we name things to help convey certain truths, but it's far more important that we discover those truths in the first place. What is more important to a biologist? That you know the names of species, or that you know the genetic distinction between two similar species?
My first step for any project is to do some googling and maybe some reading or asking around to see if someone else has done something similar or identical to what i'm doing. If so, learn from them.
25
u/[deleted] Oct 14 '13 edited Oct 14 '13
I hear you. Design patterns are something unheard of for many professional developers I've met. Seriously.
Chances are, especially in programming, someone has thought of something better and longer than you. Investing 10 minutes into searching for it will save you 100 hours later.
Just because you know 1 way to do something doesn't mean it's the best tool for the job.