Learning to Code in the '80s: What Scarcity Taught Programmers

Dave, of the YouTube channel Dave's Garage, opens his latest video with a thought experiment: imagine learning to program with zero internet, no Stack Overflow, no GitHub, no Discord, no AI to explain why your loop never terminates. Now put that kid in Saskatchewan in the 1980s—a province where, as Dave puts it, the winter climate was once best described as "hell on house cats"—and where the nearest person who knew more about computers than you might be a magazine editor in another country whose reply, if it ever arrived, would take months.

That's the setup. And then Dave says something that stops you: "The strange thing is it was almost perfect."

Not comfortable. Not equitable. Perfect the way a forge is perfect—specifically because it gives you no choice but to become something harder than what you were.

---

I want to be upfront that I find this framing genuinely interesting, not just as nostalgia but as a real question about how people develop technical intuition. Dave is describing something specific: the cognitive relationship you form with a machine when there's nothing between you and it. No framework, no autocomplete, no AI suggesting the next three lines. Just a blinking cursor and the slowly dawning realization that "SN?" doesn't mean spelling error—it means syntax error, and the computer has been trying to tell you that this whole time.

Dave's first computer encounter was a TRS-80 Model 1 at a local Radio Shack. He'd absorbed everything he knew about computers from Star Trek, so he assumed they'd understand conversational English. They did not. What followed was, by his account, a self-directed crash course in BASIC syntax through sheer persistence—because there was literally no other option.

The resource chain he describes is almost funny in how fragile it was: "If you didn't know how to open a file, you needed a manual. If you didn't have the manual, you needed a friend. If you didn't have a friend, you needed a magazine. If the magazine didn't cover your computer that month, you needed some patience. And patience was the killer app of the '80s."

The magazines were real lifelines—Compute!, BYTE, Run, 80 Micro—and sometimes they included games you could type in yourself, which Dave describes as "charming until you remember that typing in a game often meant entering six pages of dense BASIC followed by two pages of data statements that look like somebody had sneezed hexadecimal onto the page." One wrong digit. One zero that should've been the letter O. Crash.

And here's what I think is actually the most underrated part of his whole video: he argues that this process—manually transcribing and debugging someone else's broken code—is where a lot of those kids accidentally learned the most important skill in programming. Not writing code. Reading it. Learning to scan a line and ask what it's actually doing, not what you intended it to do. Learning that a syntax error on line 430 might be caused by something on line 170. "Print variables," Dave says, "because that was your only oscilloscope."

That debugging instinct—what changed since this worked last time?—is something he clearly still runs on today.

---

The hardware constraints go deeper than just scarce documentation. Dave talks about the Commodore 64's 64K of RAM, of which only around 38K was actually available for user programs once BASIC, the OS, screen RAM, and I/O took their share. The rest vanished into what he calls "architectural potholes you only discovered when your program got big enough to fall into one of them."

Before his family got a C64, they could occasionally rent a VIC-20 from the public library for a week at a time. The VIC-20 booted with exactly 3,583 bytes of BASIC free—a number Dave says he should've paid more attention to before trying to write a Zork-style adventure game. Everything costs memory: strings, arrays, graphics. The machine didn't negotiate. It just stopped cooperating.

What that forced on you was an understanding of the machine as a map. Specific memory addresses controlled the screen, colors, sound chips, sprites. PEEK and POKE weren't just BASIC commands—they were, as Dave describes them, "a side door into the machine's nervous system." When you wrote a value to a memory-mapped register and the screen color changed instantly—not through an API, not through a framework, but because the hardware was literally watching that address—that was something. Dave calls it "intoxicating," and I believe him.

His Commodore 64's 1541 floppy drive (which, hardware nerds will confirm, ran its own 6502 processor and was hamstrung by a notoriously slow serial bus—a documented hardware compromise that made disk loads painfully slow even by the standards of the day) became his next teacher in I/O latency. Waiting minutes for a disk load while the CPU sat idle taught him, years before it would matter professionally, that fast hardware doesn't mean fast software. That lesson, he points out, scales directly to databases, networks, cloud infrastructure—anywhere that a system feels mysteriously slow despite running on hardware that could "simulate a small weather system."

---

Dave is careful not to sell this as a universal good. The part of the video I keep thinking about is when he pumps the brakes on his own argument:

"I don't want to romanticize the suffering. There were plenty of kids who could have become great programmers if they'd had better access, better schools, better hardware, or even just somebody nearby who could explain what a stack was. Scarcity is not magic. Lack of opportunity isn't character building when it locks people out."

He means this. He's not doing a bit. Scarcity as a curriculum is a fantasy for people who survived it—it forgets everyone who didn't get the lucky breaks: the library that happened to have rentable hardware, the teacher named Mr. Bright who was only a decade older than his students but cared enough to send kids off into the weeds with real problems to solve once they'd outrun the lesson plan. Take those accidents away and the story doesn't have the same ending.

So the argument isn't "kids today have it too easy." It's more specific than that. The danger of abundance, as Dave frames it, is that it allows forward motion without understanding. You can assemble software from packages you don't understand, deploy it to infrastructure you don't understand, debug it by googling error messages you don't understand—and still ship something that sort of works. Until it doesn't. And when it doesn't, you need what he calls "the prairie skills": the ability to sit alone with a broken system, build a mental model of it, and grind toward an answer.

Whether today's developers are building those skills through different paths—open source contribution, systems programming communities, competitive programming, the sheer complexity of modern infrastructure—is a real question Dave's video doesn't fully answer, and probably can't. Someone learning to write Rust from scratch, or wrestling with kernel drivers, or chasing a gnarly race condition in a distributed system is doing something structurally similar to what Dave was doing at a C64 in 1983. The machine is still being specific. The bugs are still clues, not verdicts.

What's genuinely different now is the exit ramp. The abundance of tools and abstractions means you can stop asking why at almost any layer of the stack and still make progress. That wasn't an option in Saskatchewan in 1983. You asked why, or you were done.

---

Dave lands on a version of this that I think is actually the sharpest thing in the whole video:

"The curiosity is the difference between 'this doesn't work' and 'why doesn't this work.' That one word—why—to me, it's the whole game."

That's not a 1980s lesson. That's just the lesson. The frozen prairie just made it impossible to skip.

— Tyler Nakamura, Consumer Tech & Gadgets Correspondent