It would be like if I read movie reviews from a
reviewer who hates all the movies I like (or worse,
is ambivalent). I wouldn't find reading their
reviews useful.
You could read the reviews, and then only go to movies that reviewer hates. Not a guarantee, but it does decrease the sample size. Unless the reviewer hates all movies.
Yeah, movie reviews might not have been the best analogy. My general take on movie reviews is that I only use them to discover movies that I might have otherwise missed (i.e.: a bad review will never dissuade me from seeing a movie, but a good review of a movie I hadn't planned on seeing might make me see it).
And to be fair to Yelp, I've only ever really looked up Restaurant reviews, which seem to be the category of reviews that are the least useful. I don't think anything in a Yelp restaurant review short of "Every time I go here, they drag me to the back room and harvest my organs", would make me take notice one way or the other.
Interesting, as I have a number of Chuck E. Cheese tokens that appear to fit this description. Why don't we ever hear about FBI raids of kids' pizza / video game parlors?
I suspect that if the use of Chuck E. Cheese tokens as a medium of exchange were to become widespread in a given locale (one with the profile of Las Vegas) the Secret Service would take a similar interest.
Ender was deliberately put in a position where he was forced to fight back or get killed. His "handlers" wanted a dehumanized person capable of everything, including genocide.
"The task of the training battalions is to crush and completely destroy the individual, however strong a character he may have possessed, and to fashion out of that person a type to fit the standards of spetsnaz, a type who will be filled with an explosive charge of hatred and spite and a craving for revenge."
Source: http://militera.lib.ru/research/suvorov6/index.html
It's a book by Viktor Suvorov "Spetsnaz. The Story Behind the Soviet SAS". A quick and interesting read.
Violence and degradation is a common method of training soldiers. Some (not me) would say the school system is deliberately set in this fashion.
I disagree (and I have a CS degree) - the time spent getting another academic qualification would be far better spent on the more practical suggestions given elsewhere on this page.
I've found that having a degree is generally seen as more important in the UK than in the US; and I've seen more evidence of sniffiness, vague efforts to exclude people who went to the wrong university.
Another consideration is whether you ever want to work in the US. Getting a H-1B isn't easy without a degree.
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.
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?
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:
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.
Better yet, if working for a large employer see if you can get them to help pay for it. Obviously I don't know what sort of company you works for, but being depressed about working at a non-software company may be a reaction to internal rather than external factors.
It's worth asking for a meeting or lunch the supervisor, and explaining the worries about where you can go with this firm and why that lack of hardcore software prospects is worrying you a bit. It sounds very much as if you've ended up working as a mechanic when what you really wanted to do was design engines or gearboxes. If your employers aren't jerks and you've been doing a good job up to now, they may well offer some career-building assistance or advice that you might not have thought of yourself. Tread carefully, to ensure you aren't the obvious choice if the economy requires them to lay off a few people in every department ('Oh, let's get rid of yacoder, he's not that happy here anyway so he won't make a fuss'), but keep an open mind. For all you know the lack of core software openings at your company is due to management's inability to build a better programming team, and they might see your ambition to delve deeper as a valuable future asset.
