What is the point of higher education in computer science?

Thoreau daguerrotype | Wikimedia

I may have mentioned this before but nbd I’m a professional educator now, in a CS masters program, and thus have transcended you pl3bs and all your earthly cares. I set off at first light on a Monday in January, sandle-shod and freshly shaven — a bindle-stiff, new to the bindle-carrying world, with a few extra shirts, a crust of bread, and a selection of hard cheeses.

Now I find myself at the edge of the waters in a distant land, leatherbound journal in hand, scribbling notes while looking at birds or whatever: I am the modern, programming Thoreau (who, accounts suggest, was more nose than man).

I have phrased the question with little tact, but it is indeed genuine — and I am earnestly searching for an answer: What is the point of higher education in computer science?

To begin with, should computer science programs create programmers or should they create computer scientists? CS programs have a terribly difficult problem to solve. It reminds me of that time back when I lived east of the Shire in the valley of the river Withywindle. A fellow came by with a ring inscribed with a small part of a larger verse written among the Free Peoples:

Three classes for the Enterprise Software Developers under the sky,
Seven for the Neckbeards in their halls of stone,
Nine for the Web-programmers doomed to die,
One for the Complexity Theorist on his dark throne
In the Land of Mordor where the Shadows lie.
One CS Program to rule them all, One CS Program to find them,
One CS Program to bring them all, and in the darkness bind them,
In the Land of Mordor where the Shadows lie.

Mordor is lovely this time of year | Wikimedia

You see the difficulty here. How is one program to prepare all those different pursuits? What are the common elements that all of these peoples share? I suppose the common thread is “computing” — but in 2022, what jobs don’t require a familiarity with computing to be competitive? In addition, what can a program offer that the growing number of excellent, free, online resources cannot?

This is a question to chew on, not to answer in a short Medium article.

I know that I cannot explicitly answer it (nor am I qualified to), but I can describe one specific approach I think may be helpful to a broad range of those students (maybe not the complexity theorists): teaching by doing. This isn’t novel but in my CS education I literally never saw any professor do this a single time time. Specifically, thinking through problems using code, in real time, in front of students.

This is something I’ve been trying to work through, bit by bit, shedding (hopefully) my teaching incompetencies along the way. And there sure are a lot of them.

As a concrete example, consider how useful this approach is in teaching TDD. Consider the practical skills one needs to successfully develop using TDD:

1. A syntactical understanding of a unit test framework.
2. The loop: write test, run test, refactor system, etc.
3. Basic command of an editor “of some sort”.
4. An understanding of when to commit something to version control and what non-coding information to include (like good commit messages).

I’m just scratching the surface here, and I have only described some necessities for doing TDD at all, let alone good TDD. Already I’m getting to things that are generally not explicitly taught in school or on the job, and there are numerous deeper, “softer” skills I’d also like to communicate and I think I can only communicate by working it out in front of students:

1. Look at how fast your workflow can be! Look at how much more effective it is to have command line fluency than to, say, tab over to SourceTree or click a button to run your unit tests.
2. Why incredibly fast-running unit tests have an exponential impact on your output.
3. How to work through the holistic design of a system outside of unit tests.
4. How someone that’s done thousands of hours of writing code arranges their freaking windows.
5. When not to use TDD.

Crater Lake | Wikimedia

This is a toe-dip into a deep deep pool — and on the one hand, it’s unrealistic to expect students to learn… most of this in a classroom setting. On the other hand, exposure breeds dialog and thought. It leaves visual memories in their heads that may flash up when they find themselves sitting in front of a problem they don’t know how to solve. This is part of the reason we pair-program in the industry. To expose each other to the minutiae.

And to me, those minutiae are the butterflies, and the output of working with and thinking about computing is highly sensitive to these initial conditions.

Anyway, putting away the leatherbound journal for a bit — I need to get back to work.