Modern software is often written as if CPU, memory, storage, and the network will always be there when we need them. Compared to the past, it can feel that way. But that sense of abundance is mostly an illusion, and the bill eventually shows up — in outages, in spiraling cloud costs, and in systems that are harder to reason about than they should be.

In this keynote, I’ll connect lessons learned from working under real constraints — including time spent coding on a machine with 512 bytes of RAM — to the way we build systems today. Many of the habits we’ve drifted away from still matter: paying attention to how data moves, avoiding work that doesn’t need to happen, and treating limits as something to design with, not around.

We’ll talk about how layers of abstraction and convenience have slowly moved responsibility away from developers, and what happens when efficiency becomes “someone else’s problem.” This isn’t about going backward or romanticizing the past. It’s about remembering that good engineering has always meant making tradeoffs on purpose.

Along the way, we’ll see how performance issues, cost overruns, and environmental impact often share the same root cause: software that keeps doing things simply because it can.

The takeaway is straightforward and a little uncomfortable: resources aren’t infinite — they’re just farther away. And writing better software still means understanding where the work actually happens.