My first computer had 4KB of RAM.

Technically, 4K Words — the TDC-12 was a 12-bit machine, and the byte wasn’t its unit. But the constraint was the same.

The TDC-12 — India’s first indigenous digital computer. 12-bit architecture. I wrote self-modifying code on it. Not because it was clever. Because RAM was the constraint, and planning was the only way to survive.

You couldn’t waste a byte. Every abstraction had to earn its place.

And floating-point arithmetic on a 12-bit machine? Wink at the wrong moment and your computation was silently corrupted. No exception. No warning. Just a wrong answer, quietly propagating forward. You learned a particular kind of paranoia — the kind that never quite leaves you.

Four things I took away that I have never unlearned:

1. Constraints are not the enemy of good engineering. They are the teacher. Infinite resources stop you from thinking. A 12-bit machine with 4KB forces you to think very carefully indeed.

2. Planning is not overhead. It is the work. The code was almost a formality. The real engineering happened on paper, before the machine was ever touched.

3. Abstractions must be earned. Every layer has to justify itself. An abstraction that does not reduce complexity is just confusion with better naming.

4. Numbers lie if you let them. Floating-point errors are silent. They do not throw exceptions. On a 12-bit machine, the margin for error was so narrow that you had no choice but to think through every computation before trusting it. That instinct has informed every numerically stable algorithm I have written since.

Forty-something years later — the tools have changed completely.

There is something worth noting for anyone reading it now.

Modern JavaScript runtimes like V8 do something conceptually similar — and far more sophisticated. On first execution, your code runs as interpreted bytecode. As functions get called repeatedly, V8 generates optimised machine code on the fly, based on observed runtime behaviour. If its assumptions are invalidated — a variable changes type mid-execution — it deoptimises, discards the compiled code, and revises its approach. The program’s executable form changes during its own execution.

This is the V8 warmup you may have noticed in benchmarks. It is, at its core, a highly engineered descendant of the same idea.

The difference: in 1978, I did this by hand. In 4KB. With no safety net.

The tools have changed. The underlying idea hasn’t moved an inch.

One acknowledgement I have carried for a long time: none of this would have happened without Prof. S. C. Gupta of IIT (BHU), Varanasi, India, who gave me unlimited access to the TDC-12. That kind of trust, given freely to a young engineer, shapes a career. It certainly shaped mine.