In the year 2000 I was a commerce student in Mumbai with a machine learning textbook and more curiosity than sense. I wrote eight small programs to teach myself how machines learn: a digit recognizer, a spam filter, a sketch guesser, a rock-paper-scissors player that studies your habits, and four more. Plain JavaScript, no libraries, because I could not afford shortcuts and mostly there were none to take.
This July I put all eight back online, unchanged. They ran on the first try. This post is about why, and about what a quarter-century-old student project still teaches me on every job I take today.
The restoration that was not one
"Restoration" oversells it. I found the folder, copied the files onto this server, and opened the browser. Every program worked: the network learned, the filter filtered, the mind reader started winning by round six, the way it always did. No install step, no build step, no migration notes. Twenty-six years, zero maintenance.
They are live in the Y2K Lab now, preserved exactly as submitted, down to the design. Only the dark bar at the top of those pages is from the present day.
Why they survived
Software does not rot in the middle. It rots at the edges.
I have client projects from five years ago that no longer build. Not because the logic broke; the logic is fine. Something under them moved. A package was abandoned. An API changed shape. A build tool decided that version four would do things differently. Each of those is an edge, a place where my code touches something maintained by someone else, and every edge is a promise somebody else has to keep.
The eight programs from 2000 have exactly one edge: the browser. And browsers have spent three decades keeping a promise almost nothing else in this industry keeps, which is that the past will continue to work. Files in a folder, a browser to open them, nothing else. That is the entire deployment story, and it is why there was nothing to restore.
The maths did not age either
The digit recognizer is matrix multiplication, a sigmoid, and backpropagation written out by hand, because in 2000 there was no framework to hide inside. That is still what a neural network is. Everything since has made networks bigger, faster and easier to train; nothing has made them different in kind.
I fine-tune LoRA models for clients now, and the day-job stack looks nothing like a 16 by 16 canvas grid. But when you have written every gradient yourself, even once, at student scale, nothing that came after looks like magic. It looks like the same idea with better hardware. That turns out to be a durable professional advantage: you debug what you understand, and you only truly understand what you could rebuild.
What it changed about how I build
The modern projects I ship use modern tools, and they should. But the discipline underneath comes from these eight files:
- Every dependency is a promise someone else has to keep. Take the ones that earn their place; skip the ones that only save typing.
- Every build step is something that can stop working while you sleep. The fewer moving parts between the code and the running thing, the longer the thing runs.
- Boring choices age best. Plain files, standard interfaces, documented handovers. Excitement belongs in what the software does, not in what it is built on.
- The most impressive line on a project page is the date it stopped needing you. I hand over code, credentials and a runbook on every engagement, because things should keep working long after my involvement ends.
Go play with them
The Y2K Lab is open. Draw a digit, train the spam filter, try to out-guess the mind reader. The machine still learns from you, and the code will wait. It has had the practice.