Or: Why the best code I ever wrote ran on a machine your smartwatch could beat in a fight
There's a YouTube channel called Dave's Garage where Dave Plummer — the engineer who wrote Task Manager for Windows NT — talks about PDP-11 assembly, the internals of early Windows, and what it actually felt like to build software when every byte was a negotiation.
If you watch it and feel a deep, almost physical recognition — like someone is describing a world you lived in but nobody talks about anymore — this post is for you.
Because here's the thing about building software in the era of constrained hardware: it made you better. Not comfortable. Not fast. Better.
The Machine
Let me set the scene.
It's 1994. The development machine is a 486DX, maybe a 486DX2/66 if you were flush. RAM is measured in single-digit megabytes. The hard drive is 40, maybe 80 megabytes — and it is loud. You can hear it thinking.
The network is Novell NetWare over coaxial 10Base2, the thin black cable with BNC connectors that, if one terminator worked loose anywhere on the segment, took the whole LAN down. Everybody knew which user had the wobbly connector. Nobody said anything directly. It was a different time.
The development environment was FoxPro 2.6 — fast, but only if you understood exactly what it was doing under the hood.
Every one of those constraints — the RAM, the drive, the LAN, the query engine — shaped how you had to think before you could write a single line that worked.
What Constraints Actually Teach You
Here's what working in that environment forced you to learn, whether you wanted to or not.
You had to understand the problem before you touched the keyboard.
Today, with effectively infinite compute available for a few cents per hour, you can afford to be approximate. Throw data at a model, see what comes back, iterate. Load the whole dataset into memory and brute-force the answer. Spin up another instance if it's slow.
In 1994, you could not do any of that. If your algorithm was wrong, or inefficient, or made the wrong assumptions about the data, the user sat there watching the cursor blink while the hard drive screamed. There was no hiding behind hardware.
You had to think first — to have the shape of the solution worked out in your head before a single line was written.
That discipline — think before you type — is the single most transferable skill that era produced, and it's the one most at risk of being lost.
You had to know what the machine was actually doing.
FoxPro's Rushmore technology accelerated filter expressions using bitmap indexes — but only for expressions it recognized. If you understood which query patterns stayed on the fast path, your app was fast. If you didn't, it was slow, and you often couldn't say why.
That was true of everything you touched. The network stack, the file locking, the inter-process communication between platforms — each had specific, unforgiving behaviors that you either understood or debugged at 11pm.
The machine was not abstract. It was specific, and it rewarded specificity.
You had to make resources do more than their share.
Memory and storage costs meant redundancy was a luxury. A single piece of data often had to serve several different jobs at once — a record that was simultaneously a business object, a financial record, and an audit trail, with no room to duplicate it three separate ways for three separate systems.
That constraint forces a kind of clarity that's genuinely hard to reach when the easy answer is always "just add another table, another service, another database." Scarcity makes you find the essential shape of a thing, because you can't afford to model it twice.
The Specific Pleasure of Making It Work
There is a feeling that old-school developers know and rarely talk about, because it sounds like bragging.
It's the feeling of watching something run cleanly in production — for real customers, doing real work, generating real revenue — on hardware that a 2025 smartwatch would defeat without breaking a sweat. Not elegant, necessarily. Not something that would survive a modern code review. But correct. Reliable. Earning its keep, day after day, on almost nothing.
Dave Plummer writing Task Manager to fit inside the constraints of Windows NT's kernel architecture. The Apollo guidance computer doing orbital navigation in 4KB of RAM. The Voyager probe, still transmitting, running on 1970s hardware across 15 billion miles of empty space.
The pattern is always the same: the constraint was the teacher.
What We Risk Losing
This is not a complaint about modern development. Modern tools are extraordinary. The ability to spin up a Postgres instance, deploy a containerized service, and iterate on a UI in hot-reload in the same afternoon is genuinely amazing and produces real value fast.
But something specific gets lost when compute becomes free.
When you never have to think about what the machine is actually doing, you stop thinking about it. When you can always add more memory, you stop thinking about what's in memory. When a slow query can be fixed by scaling horizontally instead of fixing the query, you stop writing good queries.
The muscle atrophies.
The developers who came up in the constrained era carry something in their heads that is hard to teach and easy to lose: an intuition for what a computer is actually doing at any given moment, and a reflex to make it do less of it.
That intuition is worth preserving. Not as nostalgia — a 40MB hard drive was not better than an SSD, full stop — but as a discipline. As a habit of mind.
Think before you type. Understand the problem before you touch the keyboard. Make one thing do many things well. Know what the machine is actually doing.
Those lessons came from scarcity. They apply in abundance too.
The Constraint Was Always the Point
The specific systems I built in that era are gone now, and so are the industries some of them served — gutted by the internet inside of a decade, in some cases, faster than anyone thought possible.
But the thinking that built them didn't go anywhere.
And somewhere, Dave Plummer is writing PDP-11 code on YouTube, and a generation of developers who never touched a BNC connector are watching, rapt, because they recognize something in it.
The constraint was always the point.
Richard Roberts is the founder of DataPublisher LLC. He has been making data flow into documents automatically since 1994, starting with a 486, FoxPro 2.6, and a very loud hard drive.