Over the past two months on the trail I’ve been thinking a lot about computer science education (don’t judge me…). When I was a (non-CS) student at Georgia Tech I was incredibly disappointed to find that — at least in their intro classes — the curriculum was more “memorize various Java API’s” than learning Object Oriented Programming, or Data Structures and Algorithms. Even the most basic CS class (for majors and non-majors alike) was simply “learn python” and didn’t do a great job of teaching students to problem solve or engineer computational solutions to problems. While some of the advanced CS courses were slightly better, I also couldn’t help but feel that OOP was taught as an end all paradigm; a solution to all problems (related: Java is not OOP. Stop teaching it as OOP. It is procedural programming that happens to have objects. At least Tech had a class or two in Smalltalk for this). Tech also leaves out various common skills that will be required in the workplace. While Unix Tools 1001 might not be deserving of a full class (and something students should be expected to pick up on their own), it’s shameful that students can make it through an entire CS curriculum without ever learning to use SSH, or basic version control principles, for instance.

I have become convinced that all intro CS classes should cover the following three points:

1. Students should be able to pick the best problem solving paradigm for a given problem and express the problem and a computational solution on a whiteboard (without code) including writing tests.
2. Students should be familiar with version control concepts and basic Unix tools (git, SSH, Bourne shell, etc. — basically just how a shell and man work) without wasting classroom time teaching them.
3. Students should never be “taught a programming language”, they should pick them up while obtaining more general knowledge.

Unfortunately, I don’t command the use of a classroom where I can put these principles to the test. To that end, I began outlining (and, subsequently, writing) a textbook which could be used by such a course if some brave highschool or university were ever to entertain the idea of teaching a class this way.

The textbook is divided into three sections, each representing a programming paradigm (or, more generally, a problem solving paradigm):

• Procedural (really just a generic introduction to Imperative/Structured programming)
• Object oriented
• Functional

Each of which is taught in the context of their patent paradigms (imperative or declarative programming) which roughly split the text into two books which may be divided among semesters, or even into separate classes. A different language is used to teach each paradigm (Go, Ruby, and Clojure at the moment), but the languages are never taught. Instead, basic concepts are introduced and the student is directed to the language documentation for more examples, and language specific idioms that aren’t required to facilitate using the language for basic problem solving.

Tools such as Git and Bash are scattered throughout with only a basic introduction. Version control as a more general (not Git specific) concept, as well as tool setup, and other language related resources are included as appendices. Testing should also be taught alongside the other concepts, but as a first class citizen. Testing will be taught as part of thinking about design and programming alongside the actual paradigms.

With these goals in mind I started writing and already have a sizable chunk of text (I think I’m going to need a separate journal to dedicate to the topic out here). I can’t help but think that an intro course taught in this way would help new CS students to develop better engineering mindsets, and problem solve at a higher level early on as well as provide them with a foundation to develop basic workplace skills later on.

Hopefully I’ll be able to open source it at some point when I’m in a town with a computer (using my phone to write this post is quite enough to be getting on with). In the mean time, I’ll put some excerpts here when I can. Who knows, maybe in a few years I’ll actually have something to publish. We shall see.