Hacker News new | ask | show | jobs
by Jonhoo 2323 days ago
Over the years, we (@anishathalye, @jjgo, @jonhoo) have helped teach several classes at MIT, and over and over we have seen that many students have limited knowledge of the tools available to them. Computers were built to automate manual tasks, yet students often perform repetitive tasks by hand or fail to take full advantage of powerful tools such as version control and text editors. Common examples include holding the down arrow key for 30 seconds to scroll to the bottom of a large file in Vim, or using the nuclear approach to fix a Git repository (https://xkcd.com/1597/).

At least at MIT, these topics are not taught as part of the university curriculum: students are never shown how to use these tools, or at least not how to use them efficiently, and thus waste time and effort on tasks that should be simple. The standard CS curriculum is missing critical topics about the computing ecosystem that could make students’ lives significantly easier.

To help mitigate this, we ran a short lecture series during MIT’s Independent Activities Period (IAP) that covered all the topics we consider crucial to be an effective computer scientist and programmer. We’ve published lecture notes and videos in the hopes that people outside MIT find these resources useful.

To offer a bit of historical perspective on the class: we taught this class for the first time last year, when we called it “Hacker Tools” (there was some great discussion about last year’s class here: https://news.ycombinator.com/item?id=19078281). We found the feedback from here and elsewhere incredibly helpful. Taking that into account, we changed the lecture topics a bit, spent more lecture time on some of the core topics, wrote better exercises, and recorded high-quality lecture videos using a fancy lecture capture system (and this hacky DSL for editing multi-track lecture videos, which we thought some of you would find amusing: https://github.com/missing-semester/videos).

We’d love to hear any insights or feedback you may have, so that we can run an even better class next year!

-- Anish, Jose, and Jon

16 comments

That’s cool. Now, on to my possibly unpopular opinion: This isn’t what computer science is about. In fact, you don’t even need to use a computer to do computer science.

Sure, some stuff you learn in CS can make you a better software engineer. CS cannot make you a software engineer.

CS can definitely not make you adept at using computers and neither should it. That’s something earlier education institutions must tackle.

It’s always good to have optional courses for various topics of interest. _Requiring_ students to learn, say, MS Office (I had to), is just plain ridiculous.

Science doesn't abstractly drop from the heavens, fully formed. Every science has practical enablers that are required to get stuff done. Astronomers use telescopes, physicists/chemists/etc use lab equipment, Mathematicians use various notations and other tricks (and nowadays proof assistants) to make their job easier.

MS Office might not be practical for computer science (also note how the OP doesn't list that), but learning how to write your papers in latex might, and knowing how to use a shell certainly is.

E.g. if you'd like students to learn about type theory, they will need to experiment with your compiler. You cannot expect students to miraculously be proficient in this, and explicitly teaching them (and requiring it as a prerequisite course to signal that yes, it's important) can turn weeks of frustration followed by a huge dropout rate into a productive course.

They should be writing them in asciidoc (or even markdown) and using style sheets if they really need complex formatting!!! (although at least latex is decent at typesetting and has nice defaults.)
Does asciidoc have equation typesetting support? I don't really care what I use to write my words, everything is equally good (except for LaTeX which is abnormally good at typesetting), but I care a lot about the user experience for equations, which varies widely between programs.
I always use LaTeX style equations although I think it supports MathML if you want a WYSIWYG. The LaTeX math is the main argument for it, mathtype is kind of miserable.

The reasons I prefer asciidoc to straight LaTeX are:

1) the formatting is completely seperated from the text

2) you’re insulated from the specific rendering engine (you can use PDFLaTeX or WebKit+MathJax etc.) while still getting decent equation syntax and BibTeX.

Yes. I intended that more as an abstract example for a tool that's useful to do science, but clearly not a science in of itself[1].

Though latex might still come in handy once you actually want to submit papers to journals, or for a thesis. YMMV.

[1] then again, if I remember my feeble attempts to write latex macros, maybe the emergent behaviour of common latex packages would be a good research subject? ;-)

> That’s cool. Now, on to my possibly unpopular opinion: This isn’t what computer science is about.

This is not an unpopular opinion at all, CS degrees do not typically cover what's in this class which is precisely why they called it "the missing semester".

Yes, it is exactly this naming that somehow irks me. It somehow seems to imply that this should be part of the regular CS curriculum. It should not.

Indeed, universities should once again become a place where you go to pursue a career in science. Not a half-baked vocational training center. That’s why I’m against excessively accommodating this misuse.

Are you saying that you completed a CS degree without writing programs on a computer?

There are many great experimental physicists (including Richard Feynman), chemists, biologists, and engineers who used real hardware. Why shouldn't computer scientists use real hardware?

Wasn't it Sussman and Ableson that said that Computer Science is both not a science, and not about computers?
Yes, and MIT (correctly) dropped Sussman and Abelson's head-in-the-clouds intro class in favor of a practical one that actually teaches you about computers.

I took Abelson and Sussman's class myself, as an MIT undergrad, just before it was phased out. I got a lot out of it, because I had already been using UNIX and writing code for years at home as a teenager. If you didn't have that background it would be useless to you.

"Computer science isn't about computers" is a similar statement to "English composition isn't about pens or keyboards." If you can't use the tools, you won't get very much work done. A writer is fortunate that our grade schools generally teach handwriting and/or typing - but if they didn't, a college degree on how to tell compelling stories and understand the monomyth isn't going to help you actually write books. Computer science isn't about using editors or shells, but if you don't come in with knowledge of editors or shells, you won't get very much done.

Yup.

'Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers.' -- from the preface to SICP.

There's a similar quotation often attributed to Dijkstra, but it seems doubtful whether he actually said it.

I didn’t, because I switched to a different type of university. I could have, though.

I’m not saying science should be only in the mind or maybe pen and paper. I’m saying CS should not have a “how to computer” course.

It's not computer science. It is computer literacy.

Most people who come out of a CS course will go on to become developers, not academics. The course topics are standard domain knowledge for anyone who builds software - not because of specific tools, but because of the concept that scripting and automation tools exist to make development easier.

There is no sense in which being aware of these topics will make you less effective as an academic computer scientist, if that's what you want to be.

Also it's good to get both academics and developers to use similar tools to ease collaboration.
Astronomers do stop to study how to build telescopes, chemists do stop to study how to create glassware, and biologists do stop to study culture media.

Why do you expect CS students to thrive without learning how to use a computer?

It's only with CS where I see this crazy attitude that you don't need to know anything about the tools of implementation and experimentation in order to pursue a science.

Imagine someone trying to pursue a career in particle physics without knowing anything about how a modern particle collider works. Or someone trying to be an astronomer without knowing anything about how real telescopes work. And at least in those professions, the tools are so huge and expensive and complicated that those scientists really do need an army of technicians and operators to help them gather data or perform experiments; with computers, this just isn't the case: anyone with at least one hand can write a program on a personal computer to test their theory, so the feedback loop should be much, much shorter.

While theoretical computer science doesn't need to use computers for many problems, and the experts do not need to be extremely proficient, that does not mean that a general BSc program should not teach fundamental computer architecture and programming skills -- indeed, it would be irresponsible of them not to.

The other aspect is that CS can be experimental -- the experiments are computational ones. Large computing systems are analysed using the standard techniques of experimental science, and that needs good bench skills -- except the bench is being able to program, reason about programs, etc.

However, does a BSc program need to teach large scale software development, topics like version control and tools like git, CI, etc? No. They are more properly in a BE(Software) course or its equivalent.

Should universities teach Flash/Javascript/Python/C#/nginx/Active Directory as an end in itself? No. That is almost a technical trade qualification.

But you should be able to leave university, learn language X, program in it efficiently, and know how to learn about some system.

(I'm sorry you had to learn about Office.)

I learned tools the old fashioned way - by asking an upperclassman or TA.

I also remember taking a "Software Engineering" class and it bore little to no resemblance to any part of my 20+ year career.

It isn't at the core of the CS curriculum, and neither are general requirements, but it is highly relevant to the course work and I am willing to bet it does not only help people interested in software engineering, but also people who want to be CS academics.

Making sure students are familiar with a full featured text editor, document preparation system, a version control system, the command line, etc. will go a long way. I don't think those are topics regularly covered in earlier education institutions.

I think that's reasonable. I really wish they offered more applicable classes at lower levels of education... I did like 2 days of programmable Legos in 5th(?) grade and then had to take a basic typing / MS Office course in 9th grade (required like you). In 11th grade I took CISCO Networking, Computer Manufacturing, and an intro programming course in C++.

After high school, I did a 4 year degree in Computer Science and while I learned a lot about algorithms, proofs, FSMs, design-patterns, etc. We got very little practical experience building software.

It'd be nice if they covered version control, more *nix and text editors, extending an existing codebase, refactoring, debugging, APIs, common libraries, multiple languages, and the web in general.

I think most CS students learn to become software engineers either on the job or on their own and there's room for school to help ease that transition.

The college I went to attempted to balance these - covering both abstract concepts and concrete tools and practical skills in roughly equal measure.

I think that's fair. Some people will go on to use both to work as a programmer, some may focus much more heavily on the theory end to focus on the science part of CS.

MS Office definitely doesn't seem to have a place. Maybe for a general "computer competency" course for college students, but not as part of a CS program.

"I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it." -- Bill Gates

Some people just accept absurd drudgery interacting with computers; it never even occurs to them to seek an easier way. But if you can teach the students to be "lazy" when it comes to that kind of repetitive drudgery, they'll be set for life.

I think the problem is more a lack of imagination. They just keep doing things the way they always have.

I seem to have a surplus both of "there has to be a better way"-itis, and some skill in finding such ways.

I call it a lack of curiosity instead of a lack of imagination. Both are useful, but to me imagination is more about coming up with new solutions than understanding how something that already exists can be bent to your will.
I think they go hand-in-hand. You have to have some imagination about how something must work (however off-base) to be curious enough to find out how it really works. It often seems to me that people who aren't curious lack it because they can't even imagine something different than what is in front of them.

They don't wonder how a car works because they can't even begin to deduce how it might work, from the observable outside in, because they lack the imagination to make those deductions. Someone who's curious might see a car and think, "How does this work? I can see the wheels spin and propel it forward, but something must be making those wheels turn. How do they all spin at the same time? What turns the push of the pedal into making the wheels turn?" etc.

I see curiosity and imagination as two sides of the same personality trait expressed in different ways.

> I see curiosity and imagination as two sides of the same personality trait expressed in different ways.

That's because the world of today is both complex and complicated. Imagination is needed to decipher things and curiosity to get you the urge to find out more. I would argue that it's two different traits both selected by evolution. Let's imagine a tribe on savannah where some are smart enough to imagine lions hiding behind a hill and not sufficiently curious to find out by just going there, it's great to imagine throwing rocks to scare potential predators away. So you need both, they're complementary and might not even have to be expressed in the same individual but beneficial if they do.

I don't think it's just that. I think a lot of it is just a desire for successful results. Once you learn how to do something and it works you don't bother with asking if it's the most efficient way or not. You know it works so you just keep going back to the well. You then spend your energy on figuring out the next thing you don't know.
Three great programmer virtues, according to Larry Wall: 1. Laziness (figure a smart way to do it that is less work) 2. Impatience (figure how to do it faster) 3. Hubris (figure that what you're doing is important)
Sadly. It doesn't seem to be a real Bill Gates quote. https://quoteinvestigator.com/2014/02/26/lazy-job/

But you can quote Larry Wall on the three virtues of a programmer. http://threevirtues.com/

Since you mention scrolling using key repeat - it truly is painful to watch someone do it on default settings. And there are usually better ways to do that sort of thing. But sometimes, there is no substitute: going to the right spot in the middle of a word/line, moving around a page, browser title bars, etc. Here's the kicker though: most keyboard repeat rate settings around have a maximum that is pretty much unusable! But you can fix it thusly:

xset r rate 180 60

When I work on my computer it's like driving a Porsche. When I sit at someone else's it's like I tripped over a door threshold.

There are ways to adjust this on OSX too but it's a lot more touchy. Haven't attempted on Windows.

> There are ways to adjust this on OSX too but it's a lot more touchy

System preferences > Keyboard > Key repeat rate

Adjust the slider to your liking. Works in every app. It's been there since 1984, but to the topic, not many users poke around in system settings anymore. If you want faster than the slider allows, try this from the command line: defaults write -g KeyRepeat -int 1

That's what I mean by more touchy. I think you also can't do this without messing with system integrity protection. And, "1" is the lowest it can go which is not that low IMO. :)
Personally this is what I choose to use the mouse for - even in Vim. A scroll wheel is nicely intuitive for descending a buffer.
Well, I think the point was a different one... more like press G
We previously had the same problem at University of Copenhagen, it was called "the hidden curriculum" among students.

When the undergraduate programme was reformed a few years ago these subjects where integrated into various courses, so they could be taught in a learning-by-doing fashion. As part of the first programming and problem-solving class (F#), we also teach LaTeX, Emacs and basic use of the command line, as part of a project-based software engineering course (second semester) Git is used extensively, and so on.

Um, quick question: so should one use Emacs as the University of Copenhagen, or VIM as MIT is teaching?

(Just kidding)

That question has already been answered: https://missing.csail.mit.edu/2020/qa/#vim-vs-emacs :)
Love this. I remember it wasn't until junior year when I was reading about the theoretical underpinnings of the unix kernel that I learned what the pipe operator I'd been copy-pasting on psets really did. I mean, it's great to learn those underpinnings, but most course 6 classes assumed you already knew all these tools... if it wasn't theory, it wasn't their responsibility to teach it.

"Missing Semester" describes it perfectly. Wish there had been something like this back in my day... I remember I felt as if I had learned all the theory behind fluid mechanics but didn't know the first thing about fixing a leaky faucet in my kitchen. Keep up the good work!

My feedback is to keep doing what you're doing. Some people will talk about how this kind of mundane training might not be relevant some years later. By the same reasoning students shouldn't learn the layout of their campus or how to add and drop courses, because those skills won't be relevant after they graduate. Keep helping students not waste time now on tasks that should be simple.
I read through the article, and a lot of what you've got looks really useful. Your explanation of GIT and source control is especially valuable. These are all pretty much skills a good programmer should have, but I would make one exception.

Personally, I like and have frequently used VIM. It's a useful tool to know how to use if you need to edit text files on a GUI-less system. However, I have yet to meet a single programmer with any ability to work as a team member that chooses to use VIM while using an OS with a desktop environment. VIM does have an interesting and valuable ideology, but that ideology isn't perfect and I worry that exposing new programmers to only one command line text editor and itss specific ideology might provide too narrow of a perspective. It might be a good idea to alsi present the ideologies behind other command line text editing approaches such as perl scripting and regex in order to update many files in order to widen their perspective and consider what they need to do while selecting the tool to use.

Lots of people use Vim in a desktop environment. At Facebook I would guess that something like 20% of software engineers use it on a daily basis. It’s still an incredibly powerful editor with lots of practical application and it’s constantly being updated. If you have the right plugins it can be an order of magnitude more productive than an IDE.
I’d recommend Docker / virtual machines as its own top-level module. There’s essentially no better way than containers to make projects portable and reproducible, and containers are now essential for pretty much any production system. I’ve taught docker to a few dozen people and while they hate it at first (the learning curve can be steep) they love it in the end.

Also wish this course covered bazel, maybe in potpourri. Make is important and bazel isn’t standard but bazel is pretty important for large C++ projects.

Docker and bazel both have fairly complicated interfaces and the time set aside for a course like this is the perfect time to play with them.

Ha some MIT alum friends and I were just talking about how great it would be if something like this existed, rather than having it be left to one’s first years as a junior engineer in a company. Thanks for doing this, it’s sorely needed.
I'd recommend making a course on how to create a proper Makefile, from the beginning to the advanced level.
Makefiles are worse shell scripts. /religion

I do agree with the spirit of this though. There's a big difference between "click a button in your IDE" to compile and learning about all the code-ish things that go into a real software project:

* choosing a build system (and package system too, I guess?)

* setting up CI

* static analysis

* setting up CD

* config-as-code for managing the state of prod

* staging environments?

* production monitoring

* production alerting

I would go one step even more basic and teach touch typing. It amazes me when I watch someone code by laboriously copying some other code from somewhere else, from a full code snippet to a single variable name, paste it in and begrudgingly type what needs to be typed, slowly.

The thought that always goes through my mind when I see this is "this is your interface to code, people, shouldn't you spend a little bit of time at least trying to master it?"

Forget vim, if people just learned to type they could be twice as productive in simple notepad. Vim (which I use) raises this to another level still.

Learning to use the editor macros well, could save anyone lots of effort typing. And should definitely be in your course.
I think this is an amazing course and indeed missing. I learned the things presented in the course only after graduating CS and working at a company! They (rightly so) thought I was somewhat of a fool because I preferred to use Windows.

One thing on the data wrangling. I do think that the Linux tools are powerful, but would like to give some credits to R here. For example, merging tables (similar to SQL joins) is available in the standard library. This in combination with R Markdown for visualization makes it much more easy to use than Linux CLI tools.

Hi, how are you getting the keystrokes you type in to overlay on the video? Is there a tool you're using for this? Would be very helpful if you could make it.
On macOS, we used this excellent open-source software called KeyCastr: https://github.com/keycastr/keycastr (we used this e.g. in the text editors lecture)
We shouldn't really be encouraging people to program in vim. I mean, an 80 char line length limit is very 1995. People have massive monitors now.
Your entire file can be one line in vim, regardless of it's size.
You use Vim in your example. Get your students out of it and into something like IntelliJ IDEA or VS Code or (at a bare minimum) Eclipse.
Unpopular Opinion: IDEs suck when teaching people programming. A simple Text editor, the simpler the better, is all we need, combined with a compiler. Modern IDEs introduce a boatload of completely irrelevant concepts and complexity that just adds to the confusion. Doesn't matter which one you use.

If I was to design a CS101 course, I'd do away with Java (which is the language of choice at my university) as well. I don't know what would be the replacement; vala looks nice but the resources are lacking. My main points in choosing a language to teach would be that I can do OO in it while not needing everything to be encapsulated in classes. Also, the language shouldn't care about whitespace, because if I'm teaching a few hundred students, I'm not going to debug a boatload of mixed tabs and spaces issues.

Also, my CS101 course would be about debugging as much as about programming. Including stuff like "here is some source code, that's the observed bug, submit a corrected version by midnight x-y-zzzz and describe how you debugged it in bullet points". Unfortunately, plagiarism on these types of assignments makes them very much useless in the real world where grades depend on that.

Your opinions aren't unpopular, though maybe old school (in a good way):

https://blog.osteele.com/2004/11/ides

https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

> A simple Text editor, the simpler the better, is all we need

> I'm not going to debug a boatload of mixed tabs and spaces issues

As someone who uses an IDE, I have literally never had to worry about tabs vs spaces.

The problem isn't using one consistently, in self-written code, but students will copypaste small snippets from somewhere. While python recommends using spaces for everything, more than enough code exists that uses tabs. Now; not every IDE is smart enough to actually convert everything to whatever is set. It may work for PyCharm or VS Code, but then again, I specifically do not want to endorse any program.

Edit: Or put another way - if my CS101 course has about 500 participants (which is not unreasonable in Europe), even 1% with whitespace problems will keep you busy and from answering questions that provide real insight and understanding. Because, after all, while learning to distinguish a tab and n spaces is a valuable life skill, it's entirely not my point while teaching how to think when programming.

I think it's valuable to start with Vim, especially for non JVM or CLR languages. Learning Vim as a first step will allow the students to easily navigate and edit code on remote servers. Then, when working on a code base like Java or C#, they can install the Vim plugin for their IDE and have the advantage of a superior editing tool to go along with the tooling the IDE provides.
Why? What’s wrong with vim, gdb, and some static analysis tools like cscope and a linter?

IDEs confuse people, a lot of them start to think you can’t have the compiler/debugger/build automations without the editor and start doing stupid things because of that.

I personally can't stand IDEs, and use them as sparingly as I can get away with. I don't want the build process abstracted away from me, I want to know exactly what it's doing. Whenever I'm trying to figure something out in an IDE to fix a problem with why something didn't build correctly, I want to throw up my hands and go back to a simple text editor and the make command or some bash scripts. I dislike programs that try to anticipate me, or that fix things after I've typed them. And the part of me that grew up learning to program with 4K of memory available cries when I see how many resources are being used by it.

There are a lot of things I like about them from an editing standpoint, though. Nice for refactoring, easy to find out what arguments a function takes, easy to jump around between files. Vim with multiple buffers isn't too far behind this, though, and it doesn't bring my system to it's knees just opening it up.

I guess I'm getting old.

Or preferably all of the above and Vim, and also CodeBlocks and KEIL just in case.

Really? There's a point where you get to learn your IDE...