Constraints and the Lost Art of Optimization

In 1984, Steve Jobs walked over to a bag standing on stage and pulled out a computer that would change the world. The Macintosh had an operating system, a graphical user interface, window manager, font renderer, and a complete graphics engine called QuickDraw, one of the most elegant pieces of software ever written.

The whole thing fit inside the machine’s 64KB ROM.
Sixty. Four. Kilobytes.

A typical webpage hero image is larger. Most “Hello World” apps are larger. The entire intellectual and creative output of a team that reinvented personal computing fits in a space that, today, we wouldn’t think twice about wasting on a single font file.

They did it because there just wasn’t any other choice. A larger ROM would have been too expensive for a mass-market consumer device, so efficiency and hyper-optimization was the only route.

Somewhere in the years that followed we’ve lost the creative solutions, the art of optimization, that being constrained in that way produces.

---

The Atari 2600 game console had 4KB of ROM and 128 bytes of RAM. Not kilobytes… bytes. And because there was no display buffer, programmers had to manually synchronize their code with the connected TV’s electron beam as it swept across the screen, line by line, sixty times a second. If your code ran too slow, the image tore. If it ran too fast, you’d corrupt the next line.

They called it “racing the beam.” It was brutal, unforgiving, and it forced some of the most inventive programming in computing history.

Super Mario Bros shipped on a 40KB NES cartridge. Tetris for the Nintendo Game Boy, the most successful handheld game ever made at the time, was 32KB. These weren’t compromised experiences, they were masterpieces. The constraints didn’t diminish the work, they actually defined it.

The programmers who built these things weren’t just efficient, they thought differently. They knew their medium the way a sculptor knows stone. They understood every byte, every clock cycle, and every trade-off. The machine had no secrets from them because it couldn’t afford to.

Abundant, Cheap, Fast, and Powerful

Modern development is defined by abundance. Cheap storage, fast networks, and powerful hardware. The practical consequences of inefficiency have largely disappeared. A few extra megabytes, a few wasted milliseconds, an unnecessary UI re-render. For the most part, nobody notices and nothing breaks.

And so we’ve stopped noticing ourselves.

This isn’t out of laziness, it’s just how rational people work. When the hard limits disappear, the thinking they demanded tends to disappear with them. There’s no forcing function, no electron beam to race, no 128 bytes standing between your idea and disaster. We can afford not to understand, and so increasingly, we simply don’t.

What Can We Learn From The Past?

Here’s what I think is worth recovering: not the constraints themselves, but the relationship with the medium that having those constraints produced.

The engineers who wrote the Mac ROM didn’t just know how to be efficient, they understood their problem at a level that made elegance possible. Bill Atkinson’s QuickDraw wasn’t just small, it was a beautiful piece of code. The 64KB forced him to find the right solution, not just a working one.

That instinct, to understand deeply before you build, to ask whether this is the right structure and not just a functional one, to treat your medium as something to be understood rather than merely used, that’s the transferable thing. Not the bit-twiddling, the thinking.

The best engineers I’ve worked with carry this instinct even when others might think it crazy. They impose their own constraints. They ask what this would look like if it had to be half the size, or run twice as fast, or use a tenth of the memory. Not because anyone demanded it, but because just by thinking there could be a better, more efficient solution, one often emerges.

If you want to start developing this instinct today, the most valuable thing you can do is learn how your runtime actually works. Not at the API level, but internally. How your platform parses, allocates, renders, and executes. For web developers that means understanding the browser pipeline: parsing, style resolution, layout, paint, and compositing. For mobile developers it means understanding how iOS or Android manages memory, handles drawing, and schedules work. Understanding your platform changes what you notice, what makes you wince, and what you reach for instinctively. The engineers who built the Mac knew their domain completely, and you can know yours too.

Fast by Default

There’s a principle I keep coming back to in engineering apps for performance: fast by default. Not fast because you optimized after the fact, but fast because the thinking that produces fast software is simply better thinking. It catches unnecessary complexity early, and it produces systems that are easier to understand, easier to change, and easier to reason about under pressure.

Don’t miss the next post.

Behind the scenes on web platform features, architecture, and performance.
Monthly. No spam.

Email address

Read by developers at Google, Microsoft, and Stripe.

The Atari programmers were fast by default; they had no choice. But the discipline they practiced, that intimate, demanding relationship with their constraints, that’s a choice we can still make.

The 64KB Mac ROM isn’t just a remarkable footnote, it’s a provocation. It asks: if they could do that with that, then what’s our excuse?

Not to shame us, but to remind us that constraints aren’t the enemy of great work.
They’re often the source of it.

---