Reid's freshman year of high school, Computer Science class final exam. This was hand-written by Reid himself. You are looking at a working computer program — a game — written by hand and preserved here exactly as it left the artist's keyboard. Nothing has been corrected, reformatted, or modernized. The museum built the room; the artist built everything that moves.
Learning platforms usually start young programmers on visual blocks — colorful pieces that snap together so that broken syntax is impossible. This work was made the other way: 84 lines of real JavaScript, typed one character at a time. — pairs of brackets to balance, — semicolons to place, callbacks nested three deep — and, at every moment, one missing brace away from nothing running at all.
The complete autograph source, presented exactly as written. This is not a copy made for display: the page stores the code once, prints it in this case, and feeds that same text to the exhibit above. What you read here is what runs.
¹ ² ³ ⁴ — red marginalia mark passages discussed in the curator's notes below.
Four passages the curators single out for particular admiration.
Three ducks need three sets of coordinates, and the artist solved it with a notation of his own invention: one x per duck — x, xx, xxx, matched by y, yy, yyy. Years before anyone teaches him arrays, he has already discovered the idea underneath them: give every moving thing its own named slot, and never confuse them. Perfectly consistent, instantly readable, entirely his.
Every duck you catch calls xxreset(), which spins up a fresh movement loop on top of the ones already running — so with every catch, the duck flies a little faster. The game rises to meet the player's skill, all by itself. Professional studios employ whole design teams to build exactly this kind of escalating challenge; here it takes three lines.
A duck you had already caught could still drift past the edge and end the game unfairly. The artist saw that failure coming and built a guarantee against it: a loop that pins the caught duck's coordinate to zero, thirty times a second — timedLoop(30, function() { x=0; }). Spotting the one thing a program must never be allowed to do, then making it impossible, is the core instinct of good engineering. He has it already.
The game doesn't just end — it hands down results, addressed to you by name. Three tidy if statements sort every player into below average, average, or above average, and for the exact-match case the artist reached for ===, the strict equality operator that plenty of working programmers still mix up. A complete, polished finale: your score, your name, your standing.
App Lab programs lean on functions the platform provides — onEvent, timedLoop, setScreen and their relatives. To let the work run outside its native habitat, museum conservators rebuilt those functions in plain JavaScript (a small emulator) and staged the screens to the exact coordinates the code expects. The artist's original materials — the pixel title card, the autumn backdrop, all three ducks, the GAME OVER card, and the squeak of pump.mp3 itself — were then recovered from the family archive and reinstated, matched against period screenshots of the running game. Everything is presented as found: the white boxes around the ducks, the transparency checkerboard one of them still wears, even the Play Again button, which in the original is white-on-white and effectively invisible — the museum has left it exactly that way. The code was not altered in any way.
One behavior is preserved with particular care: when a game ends, the program deletes its own ducks (line 74) — so, faithfully, they stay deleted. The brass Reset on the frame re-runs the original from the top, exactly as App Lab's own Run button once did.
Provenance: acquired directly from the artist. Original record held at studio.code.org ↗, whose own share card for this work reads, simply: I wrote the code myself.
The museum concurs.
