Ask HN: What's missing in a CS degree?

A nice start would be actually teaching Computer Science. Computer Science is a branch of mathematics, with both theoretical and applied aspects. This does not mean that learning Java syntax constitutes as "applied". I think it should be expected that CS students pick up languages on their own in order to complete and understand theory-based assignments. Anything else is probably just pandering to people who shouldn't major in CS. This doesn't mean programming projects are entirely out; if they serve to reinforce understanding something like logic programming or pointers, then by all means they're useful. The "open source contribution" and whatnot should be done on your own time, and doesn't belong in the curriculum, period.

Remember, you don't major in Physics to learn which brand of concrete you need to build a bridge. Not teaching a concept because it isn't "used in industry" is a sickening corruption of what academia is supposed to be about.

See my comment here: http://news.ycombinator.com/item?id=1345596

I think my CS degree was very valuable (regular expressions! hash tables! discrete math! cache cache cache!), although I'd encourage absolutely everybody to pick up two degrees as long as you're there. You might as well get a jump start on domain knowledge.

Weaknesses of a CS degree:

1) At the point of graduating college, it is likely that your experience working with teams in a production-like environment will be minimal. I think I did, hmm, three labs like this? None of them produced anything close to a real software product.

2) Academics don't work like industry. I worked at the university for a bit after graduation and we still didn't use, e.g., source control, testing, etc etc. Pick your favorite best practices test, we would have scored negative. It took me a few years to learn better habits.

3) You tend to do a lot of stuff which has little relationship to what you'll be doing for the rest of your life. If I were dictator for life of the CS department, I'd have kids exposed to web programming very freaking early, because it is much more likely they'll end up doing that than fat Java client apps (what we actually did in school).

4) There are a lot of soft skills that go into engineering that some schools give short shrift to. I will defend this one to the death: the most important skill for an engineer is oral/written communication, and their ability to actually produce stuff is a distant second. We had one class on technical writing.

One thing missing is a separate programming degree. The current CS curriculum at the schools I've seriously looked at has become a muddled bunch of courses that cover many basic CS topics at a very shallow level, trying to teach good programming practices along with some theory. This trend should be reversed in a CS degree - a lighter emphasis on actual programming and a heavier emphasis on mathematical analysis, proofs, etc. There is plenty of this kind of thing that has real-world applicability only tangential to programming. Even the grad-level AI courses at the University I'm attending downplay the role of math. There is nothing wrong with this per se, but I believe that it is at the expense of the real potential of teaching people CS at the undergraduate level. IS degrees sometimes fill the role of a "programming" degree but the variety there is pretty broad.

When I left school my biggest gap was in my practical idea-to-code translation ability. I'm talking about the ability to sit down and write some useful code. I had spent the previous three years thinking about type systems, programming language design, and math, and when faced with the problem of having to make some code that would do some thing, I'd say, "What's the simplest angle from which to look at this problem?" It turns out that a much faster way for me to get well-designed working code was to just stop worrying and implement it badly, and not care about the design -- the best angle is from the inside. I've learned to artificially devalue good design.

Personally I'm not that interested in the deep mathematical side of CS. To me the two biggest problems are a poor understanding of abstraction and a lack of style.

Abstraction is so much more than "Apple is a Fruit" style OOP. Objects, processes, ideas, language... a focus on abstraction from the start is one of the reasons I think the SICP videos are worth watching.

Programmers must learn to develop their own sense of style in their code. Practice writing things until they flow and feel natural. Coding is communication, to you, your team and your computer. Try not to stutter.

Keep in mind I studied in NZ and was generally a terrible academic, we are far away from anything like MIT...

I went to a school (Georgia Tech) where the CS degree is made up of a core and several specializations which actually let you have a huge swath of classes relevant to what you want to do. I had only 2 "math type" CS courses (within the college, I additionally had Combinatorics and "Calculus 3 for CS" which was basically matrix math methods, but they we taught by the actual math department).

I do think this approach where there are lots of specialties (Software Engineering, Game Prgramming, Systems Programming, etc) allows people to get experience and training relevant to where they're going in life.

All that said: I really really really want to see realistic mentored debugging go on in a CS program. I want to see 2 students and one experienced adult, sit down and learn next to someone the ins and out of all the modern debugging techniques (debuggers, binary search, profilers, memory leak detectors, etc). None of the classes had anything like that, and that was the biggest thing missing that comes to mind.

The second biggest thing is realistic estimation methods! Until I read a book on it and practiced a lot, I was horrible at it. Very little was taught on actual methods to make useful estimations.

(Here is a non-aff link to the book who's material I'd like to see covered in a college CS curriculum): http://www.amazon.com/Software-Estimation-Demystifying-Pract...

Industry might say that CS should concentrate on churning out experienced software engineers, but they are just avoiding the responsibility for training themselves.

If you read CACM academia thinks CS is missing students. They want to dumb it down to get more people in, especially less geeks and nerds, and more women and minorities. They are looking at ways of dumbing it down and making it appeal more to the masses.

I think in general CS is missing industry contribution. I would like to see more commercial enterprises writing papers, submitting at conferences, doing research, and training graduates to become developers.

Some CS programs seem to have buckled under pressure and turned into learn-java trade schools. These places are missing computer science. Some try to simulate the working environment and focus too much on working on larger projects in teams because that is what industry wants, but we have our whole life to do that and uni can't teach that well anyway, you need real experience for that.

But in general, I think most CS programs, especially after year one are pretty good, and teach what they should be teaching.

I like them to teach the classic core CS disciplines, theory, algorithms and data structures, AI, databases, software engineering, graphics, and they should focus more on leading edge stuff that is perhaps not so well used in industry but provides interesting scope for further research. I think they should deliberately use languages, paradigms, and tools that are not (yet) mainstream in industry.

I would say that an intrinsic weakness of CS (and, probably, any other engineering) education is that a lot of the curriculum is targeted towards a past goal. CS is not just science but also industry, arguably in some ways more industry than science, and a very quickly evolving one. Not all professors can keep the curriculum up-to-date.

Fortunately, it appears to be a relatively small drawback. Particular details may change in a few years anyway; being prepared for the change is more important, as is being capable of learning, and this normally comes with a solid foundation which a good university program can provide to a good student.

This is a very general answer. I apologize that I cannot give a more detailed answer; my exposure to the CS education was through a graduate school which gives a different perspective.

I've started realizing just now that your standard CS degree is completely useless in the real world. I feel like I've learned absolutely nothing in these two years. Fortunately, a combination of real life events and comments from people on HN has opened my eyes to what I don't know. So, here's what you - correction, we - need to do to complete our education:

1. Contribute to a FOSS project, or start and manage your own. Alternatively, build a product and try to monetize it. This pretty much covers everything that your CS degree claims to teach you. Now we can move on to more important things like ...

2. Learn to meet and talk to new people. Learn how to be comfortable around people, and to make other people comfortable around you.

3. Learn to speak in public. Learn to clearly present your views and opinions to an audience.

4. Meet women. You won't get time to do this once you're a Silicon Valley billionaire ;P

5. Learn how to negotiate. Learn how salespeople and negotiators employ simple psychological concepts to get people to agree with them. Learn how to protect yourself from these people.

6. Study non-CS subjects. Psychology, economics, music, art, whatever. It's critical that you broaden your horizons beyond standard CS topics.

This is what I've figured out so far. If more experienced people have anything to add to the list, please do :)

I'm a technology ethicist (with a BSc in CS though!), so I have to jump in here and say that society-aware and ethical design principles are seriously missing. Things like how to involve the stakeholders (not just the client, but anyone who might be affected or who thinks they may be affected, or who are simply interested!) in your design process, how to decide whether your technology/program/etc. is actually wanted by society (e.g. the Genetically Modified Organisms issue in Europe, where despite the science being awesome, the public just didn't want it due to the behind-their-backs political wrangling that was going on). And last but not least, how to make sure that, before you start implementing your amazing idea, your idea is acceptable to society. Not accepted, since that's just a matter for compromise in the end, and compromise is not what ethics is about (it's about choice!).

Technology has a bad habit of arriving, and then the mess being sorted out later. It'd be great to get those creating it to realise the impact they will be making on society and do something about it before it creates the mess. Of course, regular feedback loops on how it's all going throughout the lifetime of the project are also necessary -- just look at the facebook debacle recently! And the Google wifi scandal! And I could list a whole bunch of other seriously problematic incidents in the last 10 years (which, incidentally, is around about when I had just started my CS degree).

I realise this is mostly a pipe dream, and that most CS students snore through any "ethics" classes they may have, but instead of these "why are we here?" classes, perhaps integrating ethical design principles into the general procedures for software engineering would be a start.

A large missing element is managing change - and how this relates to maintaining a successful project. I see this as one of the fundamental challenges of developing software in the real world. It's something you can largely ignore during a degree, where it is unlikely that a project lasts more than a few months. The best way to learn what challenges you'll face in the real world is to take on a long-term project. You'll make assumptions and mistakes early on which you can learn a lot from.

It would also be great to observe or join an existing project -- a project that has been around for some time but still maintains a strong momentum -- and learn from the way it works. That is, short cut some of the process by observing others that have overcome some of the challenges.

This should also teach you that there is so much still to learn about successful software projects that you'll be doing it your whole career :).

One of the best things I've heard: Be wary of anything claiming to be the real-world that is not actually in the real-world. Teaching "real-world" computer programming in school is an impossible goal. You only get the real-world experience when you are out in it. CS should prepare you for the real world, and help expose you to the real-world, but it's almost impossible to teach it. What CS does teach you is the bigger things. The bigger concepts that go beyond software engineering, or any particular project in particular. You learn how to think about big things and hard problems. CS at a university is not a prep course for your job per se. It's not a trade school. You're learning things that can be applied in the real-world but transcend the real-world. It's important to realize that there are more important things than just being able to program C# for your job.

I suspect a lot of CS departments don't encourage/teach teamwork. I majored in CS at Georgetown and never wrote code with a partner. Then I spent two years at Stanford doing a MSCS and did group work in very nearly every class...which was extremely valuable.

So, my advice: Learn to write code in a team.

I think one thing which is probably overlooked a lot and could be considered outside of computer science is communication skills. No matter where you go with your degree: academia, industry, start up or further study these are skills which you will need.

It doesn't mean you have to give up a broad education on underlying computer science principles to get these either, just include things like presentations and written reports with the theory work as you go. Team work is a contentious one as well. if there is team work you have to mark each persons contribution to the team rather than the team as a whole. I have had the experience of being lumped with some pretty terrible people work ethic and skill wise and had to produce something as a team.

I just finished my CS degree, and I think that it was worth it. I had time for self-directed projects in any language I wanted, learned about web programming, interface design, compiler and interpreter design, regression testing, prototyping, and all kinds of things that I might not have learned on my own. The only glaring problem was that the professors never had time to teach. They treated classes as an annoying distraction from research and programming, and many of them simply did not focus enough energy on teaching, and were unprepared for class.

I graduated last may as a computer science major and realized the holes in my skills were everywhere. I found that my theory was much better than my actual ability to code. It seems that schools should teach their students one oop language for three years and then start showing them what other options are out there. I found myself in the working world convinced I knew how to code in java, c++, python and php, w/o the real skills to work in any of them.

Everything of importance cannot be taught.

Degrees will always be "inadequate" compared to the fast changing world. What is important is that it gives you tools to apprehend your work and even perhaps your life.

In your case, computer science (mathematics) and fundamental languages are a must (Lisp, C, assembly...).

Get the basics right. You'll have all the time in the world to learn "business stuff".

Hmmm... I think "up-to-date" professors. I've had professors who've been teaching for decades and they're still stuck in the decade they started teaching. In some instances it's ok, but in other instances it's just obsolete and new methods to approach a certain problem have been developed since then, which they are unaware of.

Women. It hurts.

How to build things.

Stuff you learn there is valuable. But you won't know how to build things unless you--well, try building things.

USER INTERFACE DESIGN

Most cs students graduate without experience making products that normal (non cs) people can use. That's a shame, especially when you consider that some killer products (iPod, Basecamp) have largely been successful due to user interfaces.

Some CS programs are very good, it often depends on the school. Generally speaking, math has been de-emphasized too much and statistics is almost non existent.

History of Computation. Read some old papers, study the people who wrote them. I would've loved a class like that.

Math, science, and programming.

The real world.

Generally speaking, CS programs out there seem to lack both depth and breadth, be out of touch/time with "the desert of the real", and suffer from what Dijkstra called "the infantilization of curriculum". Too often do I see people who are proficient (for some value of "proficiency") in one (1) language, usually the wrong one. I believe that a CS program ought to introduce you to several languages, to a level where you can read and write programs of small to medium size (~1 kloc). At a minimum, in this day and age I would expect C, your least favorite mainstream language (though I personally would avoid Java, due to combination of a lack of an explicit reference type and a misguided OO fetish), something from the Lisp family (Scheme), and Javascript. Something from the ML family would be a bonus, though I would skip type theory altogether. Having been exposed to several radically different languages helps. I would ask everyone to write an interpreter for a simple language (in a language of your choice): something with variables, conditionals and function calls. A compiler for the same would be a nice next step. As projects go, this would be sufficiently involved to address Dijkstra's complaint part of the way.

A few people said something to the effect "the real world is missing". It's true. Majority of CS programs appear to be years out of date with respect to the industry practice, whatever "the industry" happens to mean for you personally. To some extent this is inevitable, though we could be doing a lot more to address the issue - say, as someone suggested, via a separate course, one that is updated biannually. A course like this could and should include a discussion of things like source control tools, build tools, etc. Things like resource management idioms in languages of the day should be discussed explicitly: too often graduates of CS programs assume infinite resources or automagical cleanup, especially if they come from a background in languages that are garbage collected. A course in parallel programming presented via different languages and their approaches to parallelism would be fantastically useful; I would pay money to see it on OCW or similar.

Somewhat related to Dijkstra's complaint is the following concern: people are terribly bad at thinking about complexity, at all levels - from a single source file to a system composed of hundreds of separate processes. We would do well to discuss managing complexity explicitly in CS curriculum: to make people think about difficulty of maintenance, changes to a working system, rollout procedures for uptime, etc. A seminar on the subject of complexity management, from small to large scale, with examples, would be very useful.

Incidentally, this is something I have been thinking a lot about over the last two years, in part due to conducting a metric shitload of interviews for intro positions. There are things that my CS program was missing, and things that a majority of programs out there seem to be missing; understandably, what I can say mostly applies to the former.

CSS, Javascript, XHTML, PHP.