Scaffolding supports learning
Recently, I wrote about finally learning to code, but only after passing up several earlier opportunities (link). Here's a perhaps-obvious theory about what finally worked: at Carnegie Mellon University, they are good at teaching computer science. Let me explain.
I recently learned about the idea of "scaffolding" from Hillel Wayne's newsletter. In the post, he explains that teaching TLA+ ("a tool for finding bugs in abstract models of software systems") is difficult: students must concurrently learn the ideas of modeling software, and also the concepts of the TLA+ tool, and also the literal syntax of writing TLA+. At any step of the way, you might make a mistake in any of these domains - and as a newbie, it's really hard to figure out even which type of mistake you're making.
As Wayne explains,
It takes less time to learn five things sequentially than three things simultaneously.
So, as a teacher, it's worth taking the time to "scaffold" lessons so that students learn only one new thing at a time.
At CMU, the first programming course I took was 15-112 ("Fundamentals of Programming and Computer Science"). Let's take a look at a recent course schedule. We start out with only the tiniest scope: for the first two weeks, students write Python code using nothing but numbers, conditionals, and loops. Strings are introduced in week 3, and lists and tuples are not introduced until week 6! And, it's not just that these are not required - they're explicitly disallowed, so if you use them, you will be docked points.
When I took this course, it felt a little slow. But looking back, I really understood each step that we took.
In contrast, consider a recent course schedule for the analogous intro-to-programming course at UC Berkeley, CS 61A ("Structure and Interpretation of Computer Programs"). The first project (due 16 days after the first lecture) asks students to implement a text-based version of the dice-rolling game Hog.
Less than 2.5 weeks in, students are expected to "use control statements and higher order functions" (emphasis mine) to implement a Hog dice-rolling scoring simulator with all the rules, that plays full games, and also outputs "remarks about the game after each turn, such as, 22 points! That's the biggest gain yet for Player 1.", and also implements strategies for rolling dice depending on the current game state.
That's insane. It's whatever the opposite of scaffolding is - throwing your kid into the deep end of the pool? And in those conditions, I would've drowned. Going so fast allows you to cover more material for the students who came in already knowing how to code... but what about people like me, who didn't? I'm not saying 15-112 at CMU was easy; but at the same time, it never felt like the coursework was designed to make me quit. [footnote 1]
At the same point in 15-112's schedule, I was counting the number of vowels in a string, and I'm not sure I had figured out how to run Python code outside of IDLE yet. By the time we were granted access to spicy types like strings, lists, and dictionaries, I was truly comfortable (and even bored) with writing loops and conditionals for numbers.
The next CMU CS course, 15-122 ("Principles of Imperative Computation"), is even more scaffoldy. A large section of the course is taught in the C0 (pronounced C-naught) programming language, which is like C, except it provides:
- garbage collection (freeing students from dealing with low-level details of explicit memory management),
- fixed range modular integer arithmetic (avoiding complexities of floating point arithmetic and multiple data sizes),
- an unambiguous language definition (guarding against undefined behavior), and
- contracts (making code expectations explicit and localizing reasoning).
If you've ever written C, you might notice that that covers a huge number of the footguns in the full C language.
It gives students the opportunity to learn about sorting algorithms and big-O complexity without simultaneously having to beat their head about integer promotion rules, how an int* could represent a reference to either an array or a single int, or the subtleties of malloc/free.
And it's not like these topics are ignored - they're covered later, with their own explicit lessons, taught at a reasonable pace.
[footnote 2]
Lately at work (usual disclaimer: my own views, not endorsed by my employer), I've been writing a lot of documentation on our internal tools related to cloud infrastructure in AWS, like security groups and IAM. To really understand the capabilities and limitations of our firewalls tool, you need to know about the AWS concepts of VPCs and security groups, but also about our internal models of service-to-service communication and network topology. As internal documentation, there is also assumed context about how code is organized into microservices and deployed - the official onboarding is very quickstart-oriented, and doesn't go into concepts very much. We haven't even gotten to the behavior of our actual tool yet!
It's a lot of information to synthesize, and I'm still working out how to discuss complex subject matter (or link out to some other doc for the really detailed stuff) and how to organize it all. But I'm definitely trying to incorporate scaffolding along the way.
Thanks to Christian and Johnny for feedback on this post.
Footnotes
[footnote 1] (back to content)
I'm picking on UC Berkeley's CS 61A here because I had a lot of friends go to Berkeley (go bears) and try to take this class. Many of them suffered, dropped the class, and did not continue learning computer science - anecdotally, at a much higher rate than the people I knew at CMU taking 15-112. I'm sure there are equally painful or worse "weeder" courses at other places, but this is one that I'm pretty familiar with.
[footnote 2] (back to content)
See An Approach to Teaching to Write Safe and Correct Imperative Programs - even in C*, from CMU professors Iliano Cervesato, Thomas J. Cortina, Frank Pfenning, and Saquib Razak for some insight on the design of C0 and how it supports students' learning better than the full C language.
The space below is left empty so that clicking on footnotes will scroll to the correct location.