Ask HN: “Year zero” for CS students? Use a terminal, etc
I vaguely recall something along the lines of an online "how to computer for CS" resource or class for incoming computer science students.
It covered things like using a terminal and a package manager. It might have been MIT. It might have been a free online course.
Does anybody remember something like that?
12 comments
[ 2.6 ms ] story [ 38.1 ms ] threadhttps://c4cs.github.io/archive/w18/
UIUC has a similar course which teaches a variety of commonly used tools, and is graded based on open source contributions
https://cs.illinois.edu/courses/profile/CS491TC-120198
Whereas most of the staff see the emphasis on the "science" part of the name. In more general terms faculty see a university as "training to do science", and in general terms students see it as "job training".
Since there's this disconnect in the goals, it's not surprising that the curriculum to achieve those goals is misunderstood by students.
Should students wanting to become programmers become familiar with the OS, and Git, and PHP and hosting Apache servers, and so on and so on? Sure. Those are all skills that employers will look for (and a million more besides.) But, and here's the important thing, you don't need to go to university to learn Git. There are at least 12 YouTube videos on doing that. Students have lots of time to learn that on their own.
[Aside: this is exactly why people often tell new wannabe programmers they don't need to go to university to learn skills, there are lots of online resources to do that at a fraction of the cost - They are not wrong - If you are going to university just to learn skills then you are over-paying. On the other hand if you want to understand the theory of coding a distributed database engine then university may be for you.]
When I was at university we lobbied to have COBOL added to the syllabus because "that's where the jobs were". What can I say, we were young and foolish. Fortunately faculty had heard it before, so instead we got a 2 week module, in which we learned, and delivered a (simple) assignment in 10 different languages. So 1 language per day. The lesson was simple - "If you can program in one, you can program in all the others [1]". At the end of the day the only changes are pretty much syntactical.[2] It's more important to learn "how to program well" than "this is how to program in C#". you can write bad code in any language, but understanding why code is "good" or "bad" takes a little more understanding.
So yes, they do teach you how to program, but only as a means to an end. It's only there so you can learn about algorithms, and data structures, and OS's and data storage and all kinds of other "theory". At university they didn't teach me to _write in language A_ - they taught me how to _make a compiler_ (for, and in, any language).
So yes, lists of everything CS Students should know are great. Indeed they apply to any wannabe programmer (university student or not.) But at the same time they are indeed not "university level material" and they should be learned in addition to your degree, not as part of it.
[1] Actually, as you probably know, there are 2 languages. Imperative and Functional. So, If you know an imperative one like C, then all the other imperatives are the same, just different. If you know a functional one, like Scheme, then ditto all the other Lisp derivatives. Cunningly we did modules in both....but we had been taught both (Pascal, and Scheme) as foundations.
[2] Ok sure, C++ contains concepts not in C. But it's just "C + more". So yes languages differ. Each has nuances, things they do well, and things they do badly. But learning a new-language takes days, not years. Becoming a master of the language (any language) takes longer of course. I never hire programmers "who know language X". I hire good programmers. Good programmers can learn X very, very, quickly. and yes filtering for "good" versus "bad" programmers is harder than ticking some "experience with X" box.
I recall the student who had spent (by his account) half a day trying to find a bug in his program. When he enlisted my help, I pulled up a debugger (which he was supposed to have learned, according to the syllabus) and found the bug in moments.
Or the software engineering project groups in my SE courses. They were all supposed to be using source code control. The ones who actually used it all reported that it helped immensely. The others produced uniformly poorer work.
Learning how to use tools effectively helps a student to do better lab work, and therefore reinforces the theoretical principles we are trying to teach.