Progressive Disclosure in Software Education
I’m not sure if it’s out of nostalgia or some weird sense of duty, but I spend a lot of time thinking about how to teach software engineering to kids. In honor of Whyday, let’s trap a few of those jumbled ideas in text.
“Which language do we teach?” That’s often the first question when putting together a class. It’s the wrong question to ask, but let’s take it as “which tools will underlie our curriculum?”
Three key areas form the base of the software knowledge pyramid:
- Algorithmic thought: how do I say “which of these numbers is biggest?” Hm, I’ll need this
maxSoFarvariable, then for each number… - Syntax: how do I express these algorithms in some language the machine can be made to understand?
- Realities of the system: why can’t I wait for that thread to end with
while(1);? Why can’t Iint *foo() { int x = 4; return &x; }?
Students struggle with C as a first language because they’re forced to learn all three of these areas at once. It’s too much material, too long before they can make anything.
I tried teaching kids Ruby to avoid realities of the system, but they still wasted too much time tripping over syntax.
Many say Scheme is the way to go: no syntax; no realities. But when I tried to teach out of SICP, I tripped on a critical zeroth area:
- Inspiration: I have to care enough after thinking “maybe I should learn to code” to trudge through chapters of boring foundational work.
My first childhood project was a text-based adventure, but when I dangled that carrot in front of today’s kids, they were indifferent. Most had never opened a terminal before; they didn’t care about making stuff trapped in this foreign, backwards world.
That’s why projects like Kodu, Alice, and Scratch are so exciting: their output feels realA beginners’ system is only compelling if a kid can make something his non-technical friends would want to have. When he shows off his creation—when he hears “wow, how did you do that?!"—then he’s inspired. Then he’s hooked.
On the other hand, this is what a child sees when starting Alice:
Leave the insane Java interface alone. It knows its shame. Instead, notice two things: first, the empty game world; second, the library of every available feature, ready to be dragged into place. Some would call this design A Feature. Yes, for some students, it can excite and reward a sense of exploration. But for others, I think it’s scary, a thousand piece puzzle of an empty sky.
Instead, consider The Incredible Machine. This puzzle asks: "Can you make all three guns fire?”
Most of the scene is in place. The goals are clear. A limited toolbox provides the pieces of the solution, but there are many ways to solve the puzzle. Each level is brief, so there’s frequent reward.
Over time, the player learns how each of the pieces works, and the puzzles get more complicated. The toolboxes include unnecessary pieces; the game rewards clever alternate solutions. Then finally, the kid can move to the sandbox, where an unlimited toolbox is at his disposal, and it’s his turn to challenge his friends.
What if this kind of progressive disclosure were applied to software education?
We’ve seen how rewards and structure affect learning. We’ve seen how social elements like achievements and cooperation keep players coming back. We’ve seen the sneaky power of games with implicit learning.
Why not a game about making games?
Say one level is Checkers. But it’s broken: it lets you move cardinally, and not diagonally! Now fix it. The game’s pieces are already in place, and the necessary building blocks are provided in a toolbox.
Or: you’re playing a game with an impossible AI opponent. Change the rules so that you can win, but you only get to use these bits to do it. You get an achievement if you beat the AI with fewer changes.
Or: this level’s game is partially finished. How does it end? Share it with your friends!
Or: rule-changing bits have a spatial or temporal area of effect and must be earned or found; work together with friends in an online puzzle platformer wielding these programm-y “spells.”
One idea for framing the game: the whole world’s falling apart and broken, Lewis Carroll style. Everything’s backwards and incomplete, and the player is some kind of deity fighting the forces of entropy.
I don’t have the time or resources to make this thing, but it is fun to talk about. This progressive disclosure nugget is just one Idea, and I have a few more I’d like to toss around.
Particularly (since I’m a language nerd): what’s the language look like? I’ve been testing various systems by using them to make Settlers of Catan, Tetris, and Super Mario Bros, and I have some ideas at the intersection of visual, declarative, and event-driven programming, but that’s a topic I’ll leave until after further reading and experimentation.
Interested in discussing these topics? Please, write me.
Lifted out for visual brevity: a bonus appendix of further reading.
My explorations in this field have been led by invaluable discussions with Ken Ferry, Ian Henderson, Joe Osborn, Chris Parker, David Smith, and Patrick Thomson. Thanks guys, for the content of this and future related articles—and for putting up with this topic in every conversation for the last two months.
Screenshot of The Incredible Machine from MobyGames.