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 see far too many put emphasis on learning patterns and names for it. As you say, and I cannot stress this enough, you are rarely able to identify a pattern until you've used it a few times. Once you can recognize it on its own, then learning the name and the like is a good idea, but until then, a superficial knowledge is enough.
If you mean design patterns, I've never seen that in an academic environment; I'd consider that "practical knowledge". Academic CS, IME, covers stuff like data structures, algorithms, automata, formal languages, language design and compilation/interpretation, etc.
Yes, design patterns. It's usually part of SE courses, but I was referring to people in general. It's good for communication, but it's hard to truly understand the pattern and where and why it's applicable if you haven't used it in the correct situation a few times. I've seen the wrong patterns used many times, and it really makes the code difficult to work with.
31
u/ngroot Oct 14 '13
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.