[barrkel]

Having said what I did in a brother post to yours, on the other hand I'd say that the amount of practically useful stuff in a CS degree is surprisingly small, and I learned most of it before I went to college. I'd probably rate analysis of algorithms as the most useful, but it is very simple stuff: it's just expressing the time or space used by an algorithm as a formula, a function of the input size, but discarding all but the fastest-growing term.

There's all the other stuff that you need to know, like the basic data structures, but these are (IME) hard to avoid if you've done much programming at all. I'm not sure you need to know hardly anything about hardware architecture unless you're aiming to code at a very low level, device drivers etc. Obviously, familiarity with machine code, cache characteristics, optimization at the assembly level, etc. are useful, but these things are best learned by sitting at a computer with a stack the Intel processor PDFs, an assembly timing loop and a simple algorithm you're trying to reduce the clock count on.

I'll add some of my own experience, as I got into compilers and currently work as a compiler developer. I was interested in compilers at a young age, I recall thinking hard in school about how one should go about evaluating arithmetic expressions correctly accounting for precedence. I wrote an open-source expression evaluator for the Delphi community, as part of the JEDI library. I built a regular expression compiler in Java, compiling to Java bytecode, as my final year project in college. Then, in my first job (in a software company, working on a green-field project, very lucky), I was able to point out the benefit of writing a custom compiler for a DSL to fill in a configurability-shaped hole in the architecture. After having built up this experience, I was in good shape when Borland (as it was at the time) came calling looking for an engineer for the Delphi compiler.

I don't think there's a deterministic kind of guarantee that can be drawn from this experience. But learning the whole stack of technology that you need to implement a language certainly gives you plenty of practice in a lot of the fundamentals of CS, right from data structures and parsing at the top (I personally would avoid parser generators as a didactic exercise) to machine architecture and cache hierarchies at the bottom, to details you'd rather not have to know about, like the idiosyncratic addressing modes of the x86 processor. And putting it into practice, even if it's in an open-source side-project, gives you a better angle on related opportunities.

[barry-cotter]

Having said what I did in a brother post to yours, on the other hand I'd say that the amount of practically useful stuff in a CS degree is surprisingly small, and I learned most of it before I went to college

Any chance you could give a list of that surprisingly smalll amount of practically useful stuff?

[barrkel]

I tried to: analysis of algorithms, perhaps data structures. Analysis of algorithms is the crucial one; if someone writes O(n^2) code when they could be writing O(n), and the constant factor is negligible, and they're unaware of these things, then IMO they have no business writing code that other programmers will use. They might be able to solve their own problems for their own data sizes, but they shouldn't infect the wider world with solutions that break under stress.

For data structures, it's more important to have a taxonomy, and a rough general knowledge of the kinds of data structures that are available, so that you know what's required and when, and have enough confidence to implement any given data structure as needed.

It's also nice to have the time and opportunity to look at different levels of various stacks, such as the network stack (the analog wire signals, how binary signals can be encoded on them, ethernet, IP, TCP and UDP etc.); and things like OS caching, process scheduling, etc. But where you're looking to put those kinds of things into practice, it's not difficult to take a day or two out of your time and read up on them - it doesn't take long to scratch deeper than an undergraduate course covers (IMO).

Depending on what area you target, other things can also be useful. Re compilers and languages, I'd be wary of taking the academic stance too seriously. Classic texts like the Dragon book overemphasize the analysis of finite state machines and pushdown automata, DFAs and NFAs, and the details of grammars and parsing, LL vs LALR, and generally all the data you need if you want to rewrite lex or yacc. But really, parsing is a very small part of writing a compiler and is actually quite easy, unless you're trying to parse C++ or something. And a more modern trend is to overemphasize type systems and their analogies to proof systems; I'd also steer fairly clear of these guys, as they are (IMO) primarily interested in churning out PhDs by creating new mathematical abstractions that have very little practical application.

When downplaying the practical value of much of a CS degree, however, I'm assuming that you already have pretty decent coding chops. For example, I would expect that you wouldn't be intimidated by programming competition problems, for example see some of the problems in the PDFs from this page:

http://acmicpc-live-archive.uva.es/nuevoportal/

The harder problems rely on a relatively small amount of base knowledge, but you have to be pretty comfortable with recursion, generating combinations and permutations, dynamic programming, and often a little computational geometry. The easy ones are more like warmup in how to read and follow instructions.

[arethuza]

The problem with that list is that it is going to be different for each person who got a CS degree.