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.
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.
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.
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? ;-)
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".
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.
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?
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.
https://thereader.mitpress.mit.edu/umberto-eco-how-to-write-...
'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’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.
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.
Why do you expect CS students to thrive without learning how to use a computer?
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.
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 also remember taking a "Software Engineering" class and it bore little to no resemblance to any part of my 20+ year career.
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.
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.
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.
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 seem to have a surplus both of "there has to be a better way"-itis, and some skill in finding such ways.
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.
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.
But you can quote Larry Wall on the three virtues of a programmer. http://threevirtues.com/
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.
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
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.
(Just kidding)
"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!
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.
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.
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
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.
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.
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.
https://blog.osteele.com/2004/11/ides
https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
> 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.
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.
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.
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.
Really? There's a point where you get to learn your IDE...
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