It's worth noting that neither a DeVry "degree" or a Computer Science degree will make you a programmer. If you just get the DeVry education, you will know what functions you can call in the Java core library. If you just get a CS degree, you will know what B+ trees are. But neither of those alone get you a working database management system; that requires excellent coding skill, and an excellent understanding of the underlying mathematics. "The real world" requires that you have both sets of skills; only having half the education will make you less than half the programmer.

I think this is a wider problem in our field; the "academics" don't want to admit that the "industrial" aspect of programming is important, and the practitioners don't want to admit that the academics are quite-often onto some very good ideas. Turns out that both sides are important. The practitioner doesn't want to waste time reinventing simple concepts (which is why we have code organization techniques that were popular in academia long before they were popular in industry), and the academic doesn't want to reinvent industry (turns out that knowing about automatic testing and source control make writing your new researchy programming language a whole lot easier).

So it's clear that to be an effective programmer, you need to be well-versed in both the practical and academic aspects of the field. Dismissing the practical aspects by saying they are a waste of time and that some dude from a trade school can handle them for you is ... short-sighted.

(Oh, and if Perl is a "dinosaur technology", Java, C++, and C are "pre-life self-replicating molecule" technologies. Just sayin'.)

The people I've worked with that are heavy on the academic side (MS,PhD, etc) with little real world experience have, without fail, been very mediocre and have had a hard time getting stuff done. They are either architecture astronauts or they try to turn it into a thesis paper. Bonus: I once saw someone with a MS in some computer-related field remove RAM from a running computer.

My experiences with people that have had no academic experience but lots of real world experience have been just as bad. I recently worked at a place where out of 14 programmers, only myself and three others had a degree. They all, to some extent, shared some of the same qualities: they can get stuff done (in small projects), but usually in really dumb and expensive ways, and they display a poor aptitude for learning new skills and techniques, and can't think abstractly.

I don't mean to say that a degree is everything or will automatically make you a better programmer, but in getting one, you gain a foundation that you wouldn't otherwise get from work experience alone.

That's not what I said, though. My opinion is that if you want to have longevity in your career, you need to focus on the theory. That doesn't mean that you don't learn the other stuff -- you just learn what's necessary, and move on. More to the point: when you're spending big bucks on college classes, you'd better be devoting your time to learning stuff that you can't learn from a few hours of quality time in a coffee shop with an O'Reilly book and a laptop.

For what it's worth, though, I've known many CS professors, and many industry programmers, and I wouldn't put the average of one group ahead of the other in terms of programming skill. The myth that academics don't know "industry" is a myth (but there are plenty of coders who don't know anything about algorithms).

Also for the record: I like Perl. I'm not the one calling it a dinosaur technology. I also like C++, though, so maybe I'm just old.

I would argue that you can't learn the theory until you have enough practical experience to actually implement and play with the theoretical concepts you are learning about. By not learning "the trivial stuff you can learn from an Oreilly book in a coffee shop", you are wasting your on time. The sooner you stop wasting your own time, the less of it you will waste.

Four courses that have been worth substantially more than $80 an hour to me: Japanese, Technical Writing, AI (mostly because it really should have been called Introduction To Scripting Languages), and (weirdly enough) my single course on assembly. That was entirely due to a twenty minute discussion with my professor that had an effect on me, the general gist of which was "Any performance problem can be solved by caching, if you do it right." I haven't programmed a single line of assembly in my professional career but every time a performance problem comes up I cache and the problem goes away. (And is replaced by a cache expiration problem.)

I agree with the general sentiment but I think that instead this should be taught during the first time students need to work in large groups (more than 2 people). Without suffering from not having version control, no one will care. Now, I'm not saying that we should only focus on what people think they need as students, but if there is a way to force them to understand the value of something, all the better.

Terje Mathiesen, or a follower of his? His axiom is that all optimization, or at least almost all of it, is an exercise in caching.

> go to DeVry, or read some O'Reilly books

> and hack away. Your career will be mercifully

> short and uneventful.

What a condescending thing to say.

I went to art school.

My career has been going strong for 15+ years.

Perhaps your experiences are different, but at the end of the day there is a sharp conflict of interest between the computer scientist and the programmer. Both want to solve problems, but the computer scientist seems more interested in some math problem and the programmer is more interested in building cool shit.

Implementing solutions in code is programming.

The broken assumption here is that you can become a competent computer scientist by doing assignments