Small Code, Big Statement: Why a New Wave of Programmers Is Digging Up the Dial-Up Playbook

Open a basic weather app on your phone. It probably pulls in somewhere between five and fifteen megabytes of data just to tell you it's going to rain tomorrow. A full download of Doom — the original, the one that ate entire college computer labs in 1993 — is about 2.4 megabytes. Think about that for a second.

Some programmers have thought about it a lot. And they're not happy.

The Bloat Problem Has a Name Now

There's a term floating around developer forums and indie coding communities lately: "software obesity." It's not a new complaint — people have been grumbling about bloated applications since at least the late nineties — but something has shifted in how seriously a certain segment of the programming world is taking it.

Part of what's changed is the framing. The conversation used to be mostly about performance: slow apps are annoying, optimize your code, standard stuff. Now there's a growing contingent of developers who are talking about efficiency as an ethical position. Wasteful software consumes energy. It excludes users on older hardware or slower connections. It contributes to a cycle of forced hardware upgrades that has real environmental and economic consequences.

And some of them are going back to school — specifically, to the school of thought that emerged when every kilobyte genuinely cost something.

Learning from the Constraints

Jordan Kessler is a software developer in Austin who maintains what he calls a "constraint practice" — deliberately building projects under artificial limitations borrowed from older computing environments. His current side project is a fully functional personal finance tracker that runs entirely in a terminal, clocks in under 200 kilobytes, and works fine on a machine from 2003.

"I started doing this as a game, honestly," he says. "I'd read about demo scene culture — the guys in the eighties and nineties who were making incredible graphics and music fit inside 64 kilobytes — and I thought, I want to understand how they thought. So I started imposing the same constraints on myself."

What he found wasn't just a fun puzzle. It changed how he approaches his day job, where he works on enterprise web applications.

"When you've spent a weekend making something work in 100 kilobytes, you come back to a React codebase and you start asking questions you weren't asking before. Like, why does this button need a 40-kilobyte dependency? What is all of this for?"

The Dial-Up Mindset as Design Philosophy

The optimization techniques themselves aren't mysterious. Most of them are well-documented in old programming literature — efficient memory allocation, avoiding redundant operations, compressing assets aggressively, thinking carefully about what actually needs to happen versus what's just convenient to include. What's interesting is watching developers treat these as fresh ideas.

Communities like the one gathered around the "handmade" programming movement — which has roots in the game development world but has spread considerably — have been pushing back against framework-heavy, abstraction-stacked modern development for years. The argument is straightforward: when you rely on layers of libraries and frameworks you don't fully understand, you lose control over what your software actually does and how much it costs to run.

Rachel Ng, who moderates a Discord server focused on what she calls "intentional programming," puts it bluntly: "Most developers today have never had to think about what their code costs at the hardware level. They've always had abundant memory, fast processors, fat pipes. The dial-up era forced people to think. We're trying to bring that thinking back voluntarily."

Her community runs regular challenges — build a functional blog engine under 50 kilobytes, write a chat client that works over a 56k simulated connection, that kind of thing. Participation has grown noticeably over the past couple of years.

Not Just Nostalgia

It would be easy to dismiss this as retro-computing romanticism — developers who grew up with fast internet pretending to be hobbled by constraints they've never actually experienced. And there's definitely some of that energy in the mix. But the performance case for lean code is real and increasingly well-documented.

Research on web performance has consistently shown that page load times have enormous effects on user behavior — and that the average webpage has gotten dramatically heavier over the past decade without delivering proportionally more value to users. Studies from Google and others have found that even a one-second delay in load time can tank conversion rates by several percentage points. The users most affected are the ones on mobile connections in lower-coverage areas — which is to say, a significant chunk of the actual American population, particularly in rural regions.

"There's this assumption baked into a lot of modern development that everyone has fiber and a new MacBook," says Kessler. "That's not the country most people live in. When you build lean, you're actually being more inclusive, not less."

The sustainable computing angle adds another layer. Software that demands less processing power consumes less electricity. At scale — across millions of users running applications on devices around the clock — that adds up to a meaningful energy difference. Some researchers studying computing's environmental footprint have started pointing to software efficiency as an underexplored lever.

Old Tricks, New Converts

What's particularly interesting from a cultural standpoint is how this community has developed its own canon — a reading list and reference set that pulls heavily from older sources. Books like Write Great Code by Randall Hyde, documentation from the demo scene, old issues of Dr. Dobb's Journal, Usenet archives where optimization debates played out in real time. Stuff that was written for a world of genuine scarcity is being read as practical wisdom by developers who've never waited more than a few seconds for a page to load.

Ng says she regularly recommends that members of her community go spelunking in old BBS archives and early internet forums. "There are threads out there from the early nineties where people are arguing about the most efficient way to do something, and the reasoning is just sharper than what you see in most modern Stack Overflow answers. The constraints forced clarity."

That's maybe the most interesting thing about this whole movement: it's not really about the past. It's about using the past to ask harder questions about the present. Why does this software weigh what it weighs? What does it actually need? Who does it leave out?

The dial-up era didn't have good answers to those questions — it just made ignoring them impossible. These developers are choosing to not ignore them anyway.

That feels like progress, even if the tools are vintage.