What if we took the production of technologically literate humanists and humanistically enlightened engineers seriously?
Just a Thought
One month before I was born, C.P. Snow delivered a lecture in which he lamented the wide gulf between “two cultures” – science and the humanities. Today it is easy to find enough scientists who are humanistically ignorant and humanists who are scientifically ignorant to conclude that the scene has not much changed in six decades.
To be fair, we talk a lot about how scientists and engineers need to learn about ethics and social impact and how everyone should learn more STEM (sometimes because JOBS! and sometimes because democratic participation in a tech-drenched world).
But our methods for implementing these things are pretty trite. The stereotypical approach to the former is to require an ethics or sociotechnical systems course in the undergraduate engineering curriculum, and for the latter we suggest people learn to code.
The ethics course approach is reminiscent of the same move in business schools a generation ago. The logic is akin to adding niacin to wheat to prevent pellagra. Teaching people to code as a way of generating some sort of tech literacy doesn’t even have that much logic behind it. While coding skills are a prerequisite for many, if not most, other tech courses, it’s not like our curricula actually contain many second courses that would be appropriate for non-tech students who want to be more technically literate.
And we have to admit that much of what we teach in response to concerns like those of C P Snow is more the product of university budgets, promotion regimes, faculty politics, and other non-intellectual and non-pedagogical concerns.
But what if we took interdisciplinarity seriously? Not Noah’s ark interdisciplinarity – where we bring one each of several different intellectual species into the same room or administrative unit and assume magic will happen – but actual interdisciplinarity where the thinkers and teachers actually crossed boundaries, held multiple passports, spoke more than one language. What kind of programs could we offer to what kinds of audiences if that were our starting point?
A few years ago I developed a prototype of a course of that ilk. It was called “Introduction to Computational Reasoning” and it reflected my own multidisciplinary training as much as any principled pedagogical design. My shorthand description was “the greatest hits of computer science taught as critical thinking.”
I knew there were greatest hits because I had been using them over the course of my career as a social scientist teaching sociology, social theory, cartography, and public policy. Over and over again I found myself teaching problem decomposition, abstraction, flow charts, logic, iterative solutions, recursion, feedback loops, optimization, backtracking, encryption, compression, automation, pattern generation and pattern matching, problem size estimation, data structures, functional abstraction, system dynamics, asymptotic thinking, learning, and alignment. And this is just a partial list. Each of these is a skill or perspective or tool that has utility outside the computer science or engineering major, but only a few are in the learning outcomes for that first programming course we typically offer non-majors. Why not pop more of them out and share them?
Here’s an outline of my course:
- 1. Think Slowly (primitive operations, sequence, choice and repetition, algorithms, abstraction, stepwise refinement)
- 2. Flow and Modularity (flowcharts, abstraction and decomposition, black boxes, stepwise refinement)
- 3. Numbers and Logic (binary, logic, gates, circuits, doing math with electricity, KMaps)
- 4. Information Jigs (memory hardware, encoding, primitive data types, abstract data types, JSON)
- 5. APIs (metaphors, servers and clients, CRUD, endpoints, documentation)
- 6. Repetition (iteration, loops, stopping conditions, complexity, recursion, sorting, searching)
- 7. Patterns (creating patterns with loops, weaving, tiling, dancing, regex, AI)
- 8. Automation (machines, rule following vs. goal seeking, automatons, open/closed loop, feedback, PID control)
- 9. How Machines Keep Secrets (cryptography, hashing, public/private keys, blockchain)
- 10. How Machines See (neurons, perceptrons, NN, DNN, convolutions, filters, training/test, Teachable Machine)
- 11. How Machines Learn (reinforcement learning, explore/exploit, policies)
- 12. Alignment
This was a crazy, dense, overwhelming course both to teach and to take. But it was a favorite of mine to teach and a favorite of many a student. Masters students who had been CS undergrads often said “I’ve seen this stuff before but this was the first time I got to actually think about it.”
I am playing with rendering the course as a “book” (more likely a creative multimedia digital learning adventure experience of some sort). I envision something like a curriculum of several courses or modules framed simultaneously as intense general interest courses that display a rigorous interdisciplinarity; the learning outcomes would be the actual insights, skills, problem solving techniques from CS along with tangible connections and applications to real world, non-CS problems. These could be assembled into “course flights” – sets of three or four courses that built on and reinforced one another (in modern ed jargon, perhaps, a certificate or some such).
Maybe this only works (or maybe “works best”) when it can be taught (delivered!) by authentically interdisciplinary thinkers – people who earnestly see the connections and the out of domain utility of disciplinary ideas. They will be able both to sell the particulars of the portable knowledge content in the courses AND to model the mind that is not constrained by disciplinary blinders. But if we can train a generation of experts free of those blinders, we will have made the world a better place.