Hacker News new | ask | show | jobs
by lumberjack 4980 days ago
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?
6 comments

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.