When I went to college, most universities did not offer a CS degree. (Though the university I eventually went to had a "Computer Science and Engineering" degre

When I went to college, most universities did not offer a CS degree. (Though the university I eventually went to had a "Computer Science and Engineering" degree that mixed bits of the Math Department's Computer Science concentration and the Engineering Department's Electrical Engineering curriculum.) I started my software career as a "that guy who can write FORTRAN" and eventually became interested in more computer-sciencey topics and less interested in particle physics. I wound up learning scheme by reading SICP and algorithm analysis by reading Knuth. I also lucked into a job where I got to talk to Ron Rivest every couple weeks, so probably got more access to him than the average MIT undergraduate. But mostly... getting a CS degree these days teaches you what to say during interviews. For instance, I stepped a kid through linked lists when I was interviewing for a position at Amazon. He had, of course, never heard of them and confidently informed me that hash-tables were the answer to every computer science interview question (I did not go to work for that team at Amazon.) As best I can tell, CS programs do a mix of teaching kids useful analytic skills and how to answer questions in interviews. I've hired both CS and non-CS degree holders. CS grads come with a pre-set "context" or "meta-mental-model" for how to solve computing problems. It is often very useful and I don't think you get that with other degree programs. However... in some corners of the world, that mental model is a detriment. I've had to untrain CS grads and get them to go back to first principals in some cases. I think the question is... is your organization doing something that would benefit from the contextual meta-model embedded in the CS curriculum at a typical university? Are you using Java? Are you programming server software on a posix-like operating system? How ambiguous are your requirements? And the EE kids get a bit more systems stuff, it seems. Half of the CS kids I've hired couldn't tell me how a larger or smaller cache would affect performance of a particular algorithm. All of the EE kids could. Managing ambiguity of requirements through judicious application of Gemma-esque design patterns seemed second nature to CS grads. The same concepts seemed to flummox EE grads. We are all victims of our training and the best thing you can say about someone who got an art history degree and then went into programming (assuming they can code) is they learned to analyze, design and implement software w/o the benefit of a conceptual scaffolding provided for them. They COULD be the best coders for certain types of ill-defined problems; they've demonstrated their ability to construct meta-models for evaluating real-world problems (again, assuming they can code.)