I graduated a top 50 school, that gave us an “engineering” degree but had no such similar course. There were no more than 20 students, out of 300ish, who understood the material of this course well enough to teach it. From my perspective, this knowledge was generally inversely correlated to GPA and strongly correlated to postgrad performance.
Take my anecdata for what it is, but I think these skills are strongly underrated by universities and students alike. Kudos to MIT for publishing this online; I know I would have benefitted from exposure to these topics in my first couple of years.
> these skills are strongly underrated by universities and students alike.
Universities believe their focus should be on timeless principles, and expect that students will supplement their instruction as needed. For example, teaching students the Bourne Again shell isn't useful on Windows, and declining in importance in macOS. Same logic applies to editors, but even more wildly varied. Rather than build 20 courses, one for every IDE, and then revisit the pedagogy every year as software changes, they basically lean heavily on 'you're smart enough to figure this out on your own.'
Some of this is obviously motivated post-hoc reasoning but still makes a modicum of sense -- anyone with 5 years exp could probably teach undergrads bash and git (with maybe 40 hours of prep), so university instructors with PhDs should be focusing on knowledge gained from research findings that wouldn't find their way into industry via other means.
In general, I agree with you; I’m not suggesting that the whole degree be built around these tools, just that they should be taught, preferably early on, alongside the traditional intro to CS course.
But it’s not just about the tools, there are some seriously timeless concepts and skills under the surface: regexp, environment variables, users and user groups, documentation comprehension, piping, filesystems, streams, processes, to name a handful. These apply to any Operating System or programming environment, and give some concrete foundation to the theories you learn elsewhere.
Plus, some of these tools really do merit a “timeless” label at this point. VIM, git, bash (and bash-inspired shells), and most of GNU utilities have been around for a very long time and have not been conclusively supplanted by more powerful tools.
It takes no great skill to teach any undergraduate CS class. If you’re talking about skills that are still going to be useful in 50 years, Unix scripting is probably one of the strongest competitors. More critically, the basic model of piping commands through a set of simple programs is extremely powerful and widely applicable.
Perhaps my experience was atypical, but freshman year included a course on proofs of correctness, starting from propositional logic and ending with LTL (comparable in concept to the system Lamport published as TLA+). Upper level course often included a hands-on section on PROMELA. These are not something I would expect a rando practitioner to know about or teach, and only rarely put into practice (albeit to good effect -- amazon uses TLA+ to formally verify their AWS services: lamport.azurewebsites.net/tla/formal-methods-amazon.pdf).
And that's really the value of an undergraduate degree: learning stuff industry hasn't yet widely adopted from the people who helped invent it.
I'm not trying to be cheeky, but you're proving the point: I'd argue that UNIX systems and tools are the foundation of AWS, not TLA+. Amazon was famous for being held together with Perl, back in the day.
If your service or company survives long enough for the marginal cost of applying TLA+ to it to be worthwhile, you can afford to hire postdocs to work on it. They probably have 10 people using TLA+ on it. There are probably 500 software engineering teams in the world that are mature enough where the payoff is worth it.
It's not to say that TLA+ isn't useful, or that it isn't worth learning. It's just that TLA+ is never going to be a bedrock tool in the same way that UNIX systems knowledge is.
> If your service or company survives long enough for the marginal cost of applying TLA+ to it to be worthwhile, you can afford to hire postdocs to work on it.
Judging from the Amazon open reqs I've seen, it's their SRE team writing TLA+. So like, both topics are useful; I just don't think it's worth paying a professor to teach you how to use computers when there are so many other resources available. This is why I support things things like LUGs and student jobs -- I spent like 5 years supervising student SREs for the OSU Open Source Lab, speaking at Barcamps, presenting and advising at LUGs, etc. And why a couple of PhD students are running a one month session and recording it for posterity.
> Universities believe their focus should be on timeless principles, and expect that students will supplement their instruction as needed.
Why the arbitrary distinction?
Why have teachers at all? Surely the students can learn the timeless principles on their own as well.
What matters is where teachers can add value. Sure, you don't need a tenured prof walking students through
Intro to Vim and Bash and By The Way GDB Exists", but you do very well to have a TA run a practical lab to teach these things.
I don't think it's really coming from any sort of high priesthood dedicated to the noble, timeless principles. It's just boring human stuff.
Professors aren't typically trained educators, many of them at best tolerate their teaching duties. They muddled through, why doesn't everyone else?
In sports there's a truism that "good athletes make bad coaches". Brilliant former PhD students often make bad teachers. Whatever the timeless principles might be, they're useless without some craft.
I think what's happening is that motivated individuals learn these things by doing, sometimes starting at an early age. Teaching these topics explicitly will probably not automatically turn students into 10x hackers; however it might help some. I know I cry a little on the inside any time I have to explain grep to an engineer that has been around for more than a year.
I have those skills, no one in my data science team does. The people with better communication skills, who can gain buy-in from colleagues and raise disagreements without making anyone angry, are doing far better than me despite their lower level of technical competence.
This doesn't mean they aren't important though. In academia (not CS), but we use a lot of what's covered in the op MIT guide.
I don't know if this gives an edge at all, and it's certainly 100x less important than soft skills, but there has to be some advantage to knowing how to pull a git repository or how to extract text matches from the command line without having to download or use an external application.
Interesting that you think it's inversely correlated with GPA. At my school, I feel like the people who are experts with the terminal and *nix stuff are the ones who have high GPAs because they are at the top of all the CS classes.
Take my anecdata for what it is, but I think these skills are strongly underrated by universities and students alike. Kudos to MIT for publishing this online; I know I would have benefitted from exposure to these topics in my first couple of years.