Representative Computer Science Courses

Written by J. David Smith
Published on 12 November 2015

I spent about 6 hours TAing today. It's kind of exhausting, but I enjoy it. I believe that over the course of this semester, I've developed a decent rapport with my students because I frequently I get asked for advice on things that aren't strictly class-related. Today, one student mentioned to me that they were switching majors away from computer science. Of course I asked why, and they explained it to me. I was slightly surprised, but understood completely. Their reason was they didn't enjoy the CS coursework, and didn't want their career to be in something they disliked.

One problem: the coursework is not at all representative of what one actually encounters in a job in the technology industry.

Representative?

The course I am TAing is the second programming course at UF. It's a weird class, and probably best described as a C++ course with a very wide variety of projects. For reference: the first course is in Java. Students are expected to know programming fundamentals a priori, and expect to learn how to program in C++ and some more advanced programming techniques. The projects they've done in this course so far have been computing magic squares, mimicking memory allocation using custom-built linked lists, and a lexer. Students are also working on a group project concurrently with the third (and upcoming fourth) project.

My first thought on seeing the project list was of the vi learning curve. The first and second projects are appropriately difficult, but the lexer is on another level entirely. They "just" have to implement one without any formal language definition or any knowledge of the theory behind how one would typically construct a lexer. My knowledge on this is sketchy at best, given that I haven't actually taken a compilers course. I believe the typical tool is a [pushdown automata](https://en.wikipedia.org/wiki/Pushdown_automata), which are generally automatically generated from an EBNF. I would consider this project if not difficult then overly time-consuming for me, which indicates that it is almost certainly not appropriately scaled for the *second programming course*.

That isn't what I came here to talk about, though. My problem with the course setup is that students are on their second year and have absolutely no idea how to do anything but read from and write to a terminal. And to top that off: they don't know anything but Java and C++, which are two of the worst languages in existence. Excuse my hyperbole, but I would seriously turn down any job offer if they said I'd be stuck writing Java. C++ would be negotiable if I got to do cool HPC stuff with it, but I have a great dislike for the language. The experiences they have in these classes are not only unrepresentative of work in industry, but are so far removed as to be mis-representing it!

Nobody, outside of very specialized areas, implements their own data structures. These are important, but we have a data structures class. There is no need for entry-level students to rebuild the wheel from messy blueprints when they could be doing something interesting. Very few people write command line programs for a living. They are common in OSS because libraries make them simple to write. But students don't get to use libraries outside of <iostream>, so they don't see the benefits. Not only that, but working in the terminal is easily the least intuitive part of our field. It is for power users, but command-line programs all but necessitate that style of work. You could use an IDE, but consider the bugs these can introduce. Literally today, one student's program was hanging. We tried it from `cmd.exe` and on the lab machines, *and it worked perfectly!* The IDE simply didn't handle the program's exit properly.

I had an epiphany today when the student said that. I have wanted to understand why students leave computer science, and here I found a reason I hadn't considered. It wasn't difficulty (the student is doing well in the course and is switching to a major that will probably be harder), it was dislike. They didn't like what they were shown! And I am left to wonder? Would they like what programming is actually like?

We Can Do Better

This changes my perspective. There are a lot of topics that are front-loaded but don't need to be. There is something to be said for having weed out classes, but oughtn't those be based on difficulty, not liking something? The command line, Java, C++, esoteric projects, library restrictions: all of these get in the way. What do we gain from them? The first three give marketable skills, which are important, and may warrant some early coverage for those students wishing to have an internship between their sophomore and junior years. However, are these the best skills for the jobs students want? And the latter two: are they even contributing?

My alma mater's sequence was 1 semester of Python, followed by 2 of C++. At least that covers a not-shit language, and if memory serves the projects were actually interesting. There was one lecturer in particular that stands out, although I did not get to take their course. Dave Brown taught the second C++ course, and the students worked individually on one project over the course of the semester. They implemented a roguelike game in C++, complete with a test suite. There were milestones for each stage of the project, and every student I spoke with I was a tutor at [UK](http://www.uky.edu) and so got to talk to a *lot* of fellow students about what classes they liked/didn't like actually enjoyed it.