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. No frameworks, because in 2000 there were none to reach for.
This year I rebuilt all eight from that coursework and put them online in the Y2K Lab. This post is about the rebuild: what had aged, what had not, and what a student project from a quarter of a century ago still teaches me on every job I take today.
Rebuilt, not restored
“Restored” would oversell it. The ideas, the maths and the behaviour come from the 2000 coursework: the network that learns your digits, the filter that learns your junk mail, the mind reader that watches your habits until it starts winning. The code is new, written for the browsers people use today, and the pages are dressed the way the web looked back then, because that part was fun.
The learning is still done by hand. There is no machine-learning library under any of the eight: every weight, every gradient and every probability is worked out in plain JavaScript, the way the coursework did it. Where a modern library saves time on something that is not the point, like drawing a chart or styling a page, I used one.
Where software actually ages
Software does not rot in the middle. It rots at the edges.
Rebuilding something you first wrote decades ago makes that plain. The middle of each program, the part that does the learning, is the same maths it always was. What had to be written fresh was everything around it: how the page draws, takes your input and shows you the result. Those are the edges, the places where code touches something maintained by someone else, and every edge is a promise somebody else has to keep.
I have client projects from five years ago that no longer build for the same reason. 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.
The maths did not age
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. You debug what you understand, and you only truly understand what you could rebuild. This year I got to check that the hard way.
What it changed about how I build
The projects I ship today use modern tools, and they should. But the discipline underneath comes from these eight programs, and rebuilding them sharpened it:
- Every dependency is a promise someone else has to keep. Take the ones that earn their place; skip the ones that only save typing.
- Keep the core free of the edges. The part of a system that holds its real value should not care which framework draws the screen. Then the edges can be replaced without touching it.
- Boring choices age best. Plain files, standard interfaces, documented handovers. Excitement belongs in what the software does, not in what it is built on.
- Hand over what someone else would need to rebuild it. 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, with the same maths it used in 2000.
