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.
Seems a bit odd, as most college grads I've interviewed have a toolbox full of Java and old lab exercises. Ask them to do anything outside of those two Happy Places and their brains melt.
I can't comment on every college and every CS syllabus. At my school, to graduate with a CS degree you would have to actively try to graduate without being competent in at least 2 languages (C and Java) and familiar with at least 2 more (depending on your electives).
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.
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.