Hacker News new | comments | show | ask | jobs | submit login
What did you cover in your undergrad CS degree? (catalystclass.com)
34 points by sharksforcheap 1846 days ago | hide | past | web | 53 comments | favorite

So I did EECS at Cal. And while some of these things are definitely in the category of software engineering and not computer science, I have to say that, in the few years between my undergrad and today, I've kept in touch with the community. And it's my sense that a lot of skills which one might find on this list are starting to be emphasized more: testing, version control, scale, timelines, communication -- so it does feel like undergrad curricula "get it" and are supplementing the standard courses with some generally useful stuff. Not replacing, but suggesting/providing/using some of the useful stuff in the context of the greater course.

I'm a little surprised schools didn't touch upon complexity already; that's been around for awhile. Yet, it is the biggest category in the responses, so that's probably why.

I'd also say that things like deployment, sysadmining -- browser incompatibilities? These are a lot more role-specific and better learned in situ. If the guy who knows browser incompatibilities needs to know how to do deployment, you are either (a) a pre-funding startup or (b) spreading your talent kinda thin.

I'm sure most of the responses here will say something like "I have never let my schooling interfere with my education" -- which is all well and good for you. But if we want more and better candidates, it couldn't hurt to adopt some of the best-of-the-best practices (version control!) into CS curricula.

This doesn't look like a CS degree---this looks more like software engineering requirements. CS and SE focus on distinctly different things. I might suggest changing the page title.

Many CS degrees are all there are at institutions. SE is merely a focus you can take in that.

Unfortunately, there isn't any distinction between the two yet. I would posit that very few people graduating with a bachelors of science in computer science are actually doing computer science work. I would posit that the vast majority of them are doing software engineering work. Unfortunately, it doesn't seem like software engineering is a bachelor's level degree (I know of a few M.S. Software Engineering programs, but none at the bachelor's level), there really isn't much of the way in formal software engineering education for someone who wants to go to school for a few years and then get a job.

Only one or two more check boxes on the survey are covered by a SE degree over a CS one at RIT. I think this is largely vocational degree not even SE. That might reflect an industry bias in the CS degree though (revision control required in all classes, technical writing and software engineering are required in the cs degree)

Edit: I should note that SE and CS are separate departments at RIT, there is a real difference in curriculum and that difference is not what this survey is getting at. A major in the IT department is what is closest to this survey, not SE. Somewhat anecdotal because its one University though.

The key question that some have touched on is this: What should comprise a CS degree? (E.g., should these (and/or other areas) be a part of a CS degree?)

I think the right balance needs to be struck between the academic and vocational views. Big-O, grammar, automata, etc. are the fodder of academic papers, not the Real World. But when you talk about higher ed, here's the rub: its supposed to be the theoretical foundation, not a purely vocational preparation.

The danger of the more vocational point of view is that you're supporting what I see as the slide from "skilled software engineering" to "coding". (Think the difference between having John Carmack on your team, versus some guy making $8/hr in a developing country.) This is hyperbole, but if you focus on the day-to-day elements of any job, then you're advocating for movement to a technical school curriculum (which, right or not, has a different level of career momentum, responsibility, etc.).

CS (using the term to apply to the genre, inclusive) is maybe unique in that there are very vocational components, but also very intellectual/academic components. I think, like any career, there are going to be Things You Don't Know coming out of school. Interviewing, for example. Is that in ANY university-level curriculum, for ANY major? Are you expected to be 100% "operational" in a particular job immediately after your degree is awarded? Moreover, since when are all CS jobs the same? Why should it be any different for CS?

This is what bothers me about this argument: CS is not equal to programming, and not equal to a (particular) job.

And moreover (and I think most here would agree), the greatest hallmark of a great "technical thinker" (programmer, academic, problem-solver, tester, DB admin, whatever) is their willingness, nay INTEREST, in pursuing the details of their craft beyond the structure of a class or a job or (god forbid) an employee handbook.

I don't want to work with someone who goes through the motions. I don't want to work with someone who comes out of college thinking they're prepared for their capital-C Career. I want a lifelong learner, and someone who wants to get into the guts of operations and make an impact.

Educate and train for THAT.

> Big-O, grammar, automata, etc. are the fodder of academic papers, not the Real World.

I have personally needed all of those things in the Real World.

I suspect that if more people remembered the stuff they learned in college, it would get a lot more use. "I'm never going to use this in the real world!" can be a terribly self-fulfilling prophecy.

I knew someone would come in and say that! (And I enjoyed my classes on automata.)

You're right, though. Which goes back to my question around what should be part of a formal education? I bet HN could come up with 10 years worth of courses that are "essential", plus another 10 that are "nice to haves".

The easy heuristic here is approval voting: award one point to a subject each time someone mentions it as a "nice to have", and 2 or 3 points to each "essential", then tally up the votes to get a ranking. Truncate it at four years' worth of classes, and you have a curriculum!

"(Think the difference between having John Carmack on your team, versus some guy making $8/hr in a developing country)"

A CS degree, or any formal education, has little to do with what kind of programmer you are going to be. You can take a completely vocational approach in school and move on to other work individually. Or the other way around. You will end up being the type of programmer you wish to be regardless of CS. Case in point, John Carmack. And in the other direction, the thousands of CS grads who every year simply churn out "whatever works" once they are in the field and forget about all they were supposed to be learning. I would encourage students to be less critical about what it is they are actually learning in school, because it's what you do after those 2-4 years that will really matter.

Point taken. (The problem with hyperbole is that there's always an exception: I know some very bright technical minds in "developing countries".)

But we're talking about "formal education": how do we develop strong technical thinkers?

I sincerely hope every practical developer knows the complexity and costs of their algorithms, can write a simple parser, and reason about finite state machines (ie, the non-trivial systems people build). I do get what you mean: CS is different than practical skills. Pure theory is interesting and less practical but all the things you mentioned have lots of uses in practice. You don't write a formal proof for every little thing but you use the conceptual tools.

I'd expect managers who hire young people out of universities expect the conceptual tools and the theory, with the weakness being practical experience. And I'd say this is true across all majors (even vocational schools).

And to my mind, that's the correct order: I'd rather teach someone the practical components rather than the theoretical ones while they're on the job. (Not to mention that practical components—even programming languages—are quickly out of date. Theory has a much longer shelf life.)

Oh, and here's the rub for me: I don't use my CS degree. Besides pet projects and a general understanding of technology, I am not technical. The vocational approach Catalyst is recommending would have made me a better software engineer, but more poorly prepared for other career opportunities.

I hire CS majors (and more broadly, engineers) into business positions because of the core skillset: problem solving and a desire to figure out a solution.

I didn't read anything on the site that said they wanted to specifically talk about CS degrees.

Personally I find things like version control and system administration to be things that students should learn for themselves. They should be encouraged, even actively encouraged (in fact they are already in most institutions) but there shouldn't be a class dedicated to this stuff. You are in University, studying CS ffs. If you can't learn such petty things for yourself, what good are you?

I left a lot of options blank that were in fact encouraged, and which professors would help us with if asked, but were not really part of the curriculum. For example, we were strongly encouraged to use version control for our group projects, especially in third and fourth year courses (like operating systems and theory of computation) and obviously estimating timelines is a necessity for any project (computer science or otherwise). Code testing is a big one I wish we would have learned or been encouraged to learn, since I'm still horrible at that, but I hear that same sentiment from nearly every programmer I've ever met, so I suspect a handful of college lectures wouldn't have helped much.

I had a second year CS course where each student was required to submit test input/output as well as their code, and a portion of the marks was derived from the coverage of these (as measured by gcov).

But the reasons for testing weren't really emphasised or even discussed.

(And a first-year course where we were required to use jUnit in the assignments, although again it was incidental and not at all a focus.)

> Code testing is a big one I wish we would have learned ....so I suspect a handful of college lectures wouldn't have helped much.

I took a "Software Testing Theory" class in the 2nd year of Software Engineering, then every course after that we were using jUnit (or whatever) for unit testing, and writing Software Test Plans and executing them on everything we did.

It was great.

Awesome -- which school?

Swinburne University - Melbourne, Australia.

This is exactly the sort of condescending attitude that pisses me off about the CS program I'm currently concluding. Why should software engineering be considered "petty" in relation to, say, the study of formal languages and automata?

The vast majority of students in my program honestly don't give a flying fuck about the academic opinion that CS shouldn't behave like a vocational school - the intent is to go into software development, and CS is the only offering that touches on it. Yes, we're all capable of learning various things on our own (including the theoretical aspects of CS, as instructors in these fields are typically so incredibly incompetent that students are required to teach themselves, anyway), but that's not a justification for providing an education that is largely irrelevant.

If I really wanted to study theory and computational mathematics... I would have studied computational mathematics.

Were it not for the perceived value of a CS degree, I suspect a substantial number of students wouldn't even bother, and probably flock to Coursera, etc.

Well, it sounds like you signed up for fine arts when you actually wanted to be a carpenter.

And you're forgetting companies like Google, Amazon, etc. who expect candidates to know CS theory pretty thoroughly. What kind of school would be proud of grads who couldn't get into one of these top companies? Software engineering is also easier to pick up on the job than in school, and vice versa for the theory.

It's condescending to describe CS theory as "largely irrelevant", but this also sounds like a case of sour grapes. There are plenty of tech curriculums that are light on CS theory--try looking for "Informatics", "IT", "Information systems" and so on.

> The vast majority of students in my program honestly don't give a flying fuck about the academic opinion that CS shouldn't behave like a vocational school

The vast majority of students in your program are unqualified to have an opinion. There's no point in having a university teach you version control systems if you're just going to end up learning it anyway. It's basically impossible to make students good software engineers (which has nothing to do with version control systems or other trivial things like that) in an academic setting. That's only something which comes with experience.

I do think it was a mistake for the parent to refer to it as "petty". Maybe some of it is petty, but a lot of it are valuable skills that you learn on the job.

But that is the key phrase, "on the job". I know I personally didn't go to school to fit all these check boxes. It seems like a poor choice to me that you and your classmates would (1) enter into a CS program without much interest in CS, then (2) blame the field of study for not being interesting to you. I for one am glad I got a CS degree (for the CS degree's sake) and thankful for what I was exposed to in those years. These other check boxes? Sure they are valuable. That's what my first job was for.

> Were it not for the perceived value of a CS degree, I suspect a substantial number of students wouldn't even bother, and probably flock to Coursera, etc.

Yes, well maybe they should get on with it then.

The beauty of CS is that the theory is directly applicable to the practice of software engineering. And because of this close connection between code and theory, you can develop significant coding skills just from doing the problem sets. As per the usual academic refrain, you get out of it what you put in.

If you think they should just be teaching you industry skills then you're wasting your time and money because college will never be as instructive as taking an internship in an actual company shipping code. Not only that, but you're paying for the privilege instead of being paid. Even if they rolled over and decided to go this route, academia does not have the knowledge or experience of what it takes to be successful in industry, must less impart that knowledge to you.

If you're going to go to college, take advantage of the academic strengths: the deep knowledge, the curiosity that goes beyond the immediate problem, the great minds you have at your daily disposal.

On the other hand, if your CS program sucks then it sucks and I'm sorry.

I agree version control does not need it's own course, but certainly a course that forces you to use version control is a good idea.

I'm currently trying to convince my organization to use version control, and because nobody has ever used it before, they just see it as a pain and more overhead that it's worth. To be perfectly honest, I felt exactly the same way before I was forced to use it for a 2nd year programming course.

Of course, since then, I refuse to not use it, even for my side projects where I'm the only contributor.

That's how it worked in my university. The C++/data-structures course sort of doubled as a "good coding habits" course. The formal course content was an introduction to OOP (via C++) and standard data structures, but we were also expected to format our code well, understand what a useful level of commenting is, understand testing, and use version control, and there were parts of lectures devoted to those. The course was taught by an old-school Unix greybeard, though, so the version control system we used was RCS, of all things.

My Software Engineering degree had a course called Personal Software Process that covered all of that and more. It was fantastic as it really emphasized how code quality and controls are the responsibility of the individual engineer.

Things like version control should be taught along with the "first week setup" stuff in courses that cover CS topics. For example, in your CS101 class you should learn how to do some basic version control while you're learning to write your first Python/Java/whatever "Hello World". This way you can all be learning about Git (or whatever is being taught) together and students and maybe TAs can help out with skills (though email, course discussion pages, etc) so that the professor can spend more time on course content.

One of the big values of college is having a lot of other people around you learning the same things at the same time. This can be helpful when learning about subject matter and about tools like version control.

While I agree that a course on version control wouldn't make any sense, I'm pretty torn about this. Most of the developers I know have shitty git habits, and it's not an accident.

I think the best approach is to integrate tasks like version control across many subjects.

For instance, many programming exercises in various subjects taught at my university give the students a basic framework with missing functions, or a test harness, or some other piece of code that needs to be finished. These could have been shared via a version control system, and delivery could be made that way as well (using pull requests, branches, or some other feature).

That way, students would be encouraged to use version control while working on the exercises.

The way it actually is done here, though, is basically "learn version control yourself and justify your choice of version control system in your report" when doing group projects.

I agree with integrating version control into the exercises/labs. When I was at school, we had to submit our work over email/Blackboard, but submitting work through a version control system makes much more sense.

Or even better, why should the university waste time teaching me petty things like version control instead of focusing on things that I cannot learn by myself.

-Philosophy of science, the scientific method

-Object-oriented programming

-Basic calculus

-Basic discrete mathematics

-Linear algebra

-Algorithms, data structures and asymptotic analysis

-Basic compiler design

-Theory of computation, Turing machines and formal languages

-Basic practical computing technology, from the gate level

-Basic software engineering: SE methodology, version control and developing software in a team

-Cryptography, ciphers and data security

-Overview of the role of operating systems

-Networking, encapsulation and the TCP/IP stack

-Basic web technology, server-side programming and client-side scripting

Anything outside of this, I've learned on the job or in my spare time. This includes AJAX and the use of heavier web technology. To my intuition, this is more descriptive of an undergrad degree in computer science rather than a software engineering degree. But it'd be nice to hear what others think.

I don't see what OOP has to do with Computer Science. Isn't that Software Engineering?

I agree, but this is where my department is being pragmatic. A computer scientist with no experience at all in OOP or basic software engineering will initially be pretty useless in the private sector, which is where 90% of graduates go.

On the results, rather than displaying the % of votes that each subject received, it would be more helpful to show the % of voters that selected it.

Instead of this:

Total voters: 613

Total votes: 3168

Designing data structures (543 votes, 17%)

Show this:

Total voters: 613

Total votes: 3168

Designing data structures (543 votes, 89%)

Browser incompatibilities? That's a candidate for the 'information to be most quickly rendered outdated/irrelevant after graduation' award. I would rather spend my $1400 a credit hour on poetry workshops (and I did.)

Are American universities really that expensive?

I graduated with a CS degree ten years ago and I could only check the following:

Designing data structures Analyzing algorithmic complexity (Big O)

Version control was glossed over in my class with little importance given to it.

Yes, the date when one was studying is a vital facet of the data being gathered here. It's a big oversight IMO to have missed out on asking a question to gain date information (eg graduation year).

I've only got, in this respect, an undergrad diploma in computing and covered 6 of these things in any depth; it would be around the same time as you were studying and we never covered version control at all.

The table of results is hard to read. More contrast between the results bars and the background would help.

"We believe that the bar for training and hiring of front end JavaScript developers is even more attainable, and that is why we have chosen to be the first, and as of now, the only training program specifically for that market."

You know what I want--a twelve week, intense course on scientific computing in something like Python--for people who already know some core scientific subject and statistics. If we took http://www.drewconway.com/zia/wp-content/uploads/2010/09/Dat... as a guide (and yes, yes, data science is just a name for something that has existed for twenty years), I want a program to move people from traditional research to data science.

I feel like there should be a follow up survey asking recent grads what their degree enabled them to learn outside of their coursework.

My CS degree hardly taught me anything in comparison to everything I learned outside of my coursework, but I don't feel like my coursework was lacking. On the contrary, my education allowed me to learn new things on my own that would have been significantly harder otherwise.

eg a basic algorithm course lead me to get involved in TopCoder. An introductory course on software development (source control, testing, etc) gave me enough knowledge to find an internship where I learned about peer reviews and how to work effectively with a large codebase - something that is very hard to pick up in a semester of college.

I got to check three of these, but one (version control) was only because I took game programming. A person could easily earn a CS degree from my school without using version control for any class.

One thing that I wish my undergrad CS degree taught me was how to manage and structure larger programs. It's a vast topic that I still have a lot of difficulty with two years into my career.

So did anyone ask these same questions to businesses that hire CS grads? How about business that hire programmers/non-CS grads? Would be useful to see the flip side.

CompSci should include at least a semester or two of business classes, including the delegation lessons in the HBS article posted earlier today.

Be careful when saying things of the form "$DEGREE_PROGRAM should also include at least one class in $SUBJECT." You can make persuasive arguments for the relevance of a dizzying range of subjects, and at some point you have to prioritize.

Very little that was directly transferable to the real world. Some may argue this doesn't apply to CS, but I think applied computing science is what I'd look for.

Things that were not covered included:

- Basic business skills

- Basic sales skills (We all have to sell our ideas, be it to peers, departments, customers.)

- Storytelling skills

- People networking skills

- Understanding very few businesses have technology problems, but instead business problems that they are trying to solve with technology.

- You don't understand anything if you don't understand how the data in any system inputs, exists, interacts, and outputs. You don't understand the business if you don't understand the data. You should not be allowed anywhere near building software for an organization if you don't understand the data.

- Understanding that the data in many ways is the system. No software/system is useful without data.

- Learning an organization's competitive advantage and magnifying it with software. Too often programmers interpret things killing the competitive advantage.

- It's not about you, it's about the user. Users rarely care what you code in, or the frameworks, or whatever you've done to make your own life selfishly easier and continuing to neglect actually getting to know their world, their data, and the the problems they face with it.

- Marketing skills - eliminate feature babble and focus on benefits once you've been in user's shoes working on users problems.

- Communicating with the world to first understand, and then address their needs. You are no better than a technically clueless business guy if you make assumptions as blindly in other ways about the business process.

- How the real world does not start every project with a clean slate like CS projects. This is probably one of the biggest gaps.

- Learning to learn other people's code, refactor + more.

Instead, we learned the theoretical using many languages building the same kinds of things over and over for 4 years. It was awesome to the geek in me. Sprinkle in some UI or database skills, and yes, I did get very good at learning any technology I needed, but implementing it in a meaningful, sustainable way. But the real world used very little of what I learnt for 4 years.

When I took CS in the late 90's I had to learn to build web apps, databases, load balancing, administrating servers, all on my own, not to mention getting a business education largely by learning to swim by diving in.

The social skills are really big. Partially I think CS attracts folks that aren't extroverted, and it can be a problem.

We're at or nearing a crossroads in my opinion where the entire world has come to the internet and technology, and those building technologies and online need to be better bridges in interfacing with humanity.

Where I went to school (Purdue) there was the school of engineering and the school of technology. The theory (at least) was that technology had more of the business side of skills as you suggest.

The downside was that more time on business meant less time on engineering, and you ended up with people that dropped out of the engineering school, combined with people that may not have been able to hack it in the first place, and a tiny minority of people that could have passed in the engineering school.

This means that as a signalling tool (which is a large part of the value of a college degree in the workplace) a technology degree was far less valuable than an engineering degree, which causes a feedback loop to keep the number of people with actual engineering talent low in the Tech school.

This is from my observation of EE vs EET as I knew people in both majors. CS was in the school of science, not engineering so it had no equivalent in the school of technology.

I am not surprised with "Interviewing candidates" getting low score, but it did receive some votes.... any proof?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact