1980s: Learning To Code Back in the '80s!

Añadido: 2026-05-27

[00:00:00]Everybody was >> Hey, I'm Dave. Welcome to my shop.

[00:00:06]Imagine trying to learn programming with no internet, no YouTube, no Stack Overflow, no GitHub, no Discord server full of people who've already made the exact mistake you're making and no AI patiently explaining why your loop never terminates. Now, put that kid in Saskatchewan in the 1980s with a winter climate I once best heard described as hell on house cats and where the nearest person who knew more about computers than you did might be a magazine editor in another country whose answer would arrive if you were lucky sometime in the next few months. That was the environment. And the strange thing is it was almost perfect. Not easy, not convenient, not fair, but perfect in the sense that a forge is a perfect place for steel. It was cold, isolated, expensive, slow, and wonderfully unforgiving. And if you were a kid trying to learn programming there, the first lesson wasn't syntax. It wasn't variables. It wasn't go-to, although there were certainly a lot of those. The first lesson was that the machine did exactly what you told it to do, not what you meant, and it would sit there blicking at you all night until you figured out the difference. Now, Saskatchewan in the 1980s was not Silicon Valley with wheat fields. It was a place where distances mattered. The towns were spread out by hours, and the winters were serious. And information moved at the speed of paper, mail trucks, and whatever the local Radio Shack happened to have in stock. If you wanted to learn computers, you were not joining a movement so much as discovering a strange little glowing island in the middle of a very large ocean all by yourself. And that island usually began with a single prompt, ready. That little word was magic. on a Commodore or a TRS80 or a PET or an Apple 2 if you happen to get one at school. The computer didn't boot into a cheerful dashboard asking you to create an account. It didn't update itself for 20 minutes. It didn't ask you to agree to new terms of service before you could type. It just powered up into Microsoft Basic and Basic was both the operating environment and the invitation. It was if the machine were saying, "Well, here I am. What are you making?" The challenge, of course, was that you had to know what to type. And that was not a small problem. The very first time I ever touched a computer was a TRS80 Model 1 Level One with 4K at my local Radio Shack. Everything I knew about computers prior to that came from Star Trek and similar TV programs. So, I presume they spoke conversational English. They did not. No matter what I typed, the response was the same. SN question mark. At the time, I was sure that meant spelling. So, I agonized and tried to get everything correct, but it actually means syntax error. And so through some useful combination of curiosity and persistence, I was eventually able to figure out the essential syntax of basic. Now today, if you don't know how to open a file in Python, you search for it and you get 6 million answers. 4 million of which are wrong, but at least they come back instantly. Back then, you didn't know how to open a file, then you needed a manual. And if you didn't have the manual, you needed a friend. And if you didn't have a friend, you needed a magazine. And if the magazine didn't cover your computer that month, you needed some patience. And patience was the killer app of the 80s. Now, I don't want to go on a rant here, but I think that psychologically the single biggest difference between the Gen X experience in the 1980s and kids today is that we had to manage our own boredom. If you were a lash key kid who came home to an empty house after school and had to entertain yourself, you couldn't just doom scroll TikTok. You couldn't text or email friends or any of that. If you didn't have premium cable, as I did not, then you could maybe listen to music.

[00:03:18]So, you likely put on an album of some kind. But because the tiny dopamine bump that you get from skipping to a new song somehow doesn't rise to the level of getting up, walking over, fast forwarding, searching for a track, overshooting it, backing up the tape, and so on. Today, it's just a flick on the screen. It used to be a whole operation. And so, patience was a virtue, and in very many tangible ways, it's a virtue that still pays off today.

[00:03:40]Now, as I was saying, magazines were a great source of information. Authors like Jim Butterfield could really demystify a system and make it all make sense. So you'd go down to the news stand, you'd hunt for Compute or Bite or Run or a Hoy or 80 micro or whatever else looked like it might contain something useful that month. Sometimes the cover promised a game that you could type in yourself, which sounds pretty 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 hexodimal onto the page. one wrong digit anywhere, one comma in the wrong place, one zero that should have been the letter O, and the whole thing would either crash, lock up, or do something profoundly weird. Soon enough, they would add checksums and so on. But even that was insufficient bomb for what was truly a painful process. And there was no debugger in the modern sense. You were the debugger. You were also the test department, the build system, the release engineer, and the customer support line, which was convenient because you were also the only customer.

[00:04:37]This is where a lot of kids accidentally learn the most important skill in programming. not writing code, but reading it. You learn to scan a line and ask, "What is this actually doing?" You learn to distrust your eyes because your eyes would cheerfully slide into the same typo 20 times. You learn that a syntax error on line 430 might actually be caused by something on line 170. You learn to print variables because that was your only oscilloscope. You learn to comment things out, to make the problem smaller, to change one thing at a time, and to ask the immortal debugging question, what changed since this worked the last time? That question alone has solved more bugs than all the fancy tools ever invented. Storage was another education in humility. If you had a cassette drive, saving a program meant listening to the squeal of data being converted into sound. Trusting that the tape wasn't worn and the volume was right and the cable was well seated and that nobody bumped the table. Loading a program could take minutes, and it might fail at the end for no obvious reason, which meant you got to go through the whole ritual all over again. It was like compiling over a telegraph wire while a raccoon chewed on the transformer. All too often, the raccoon would win and your tape was toast. A floppy drive was a real luxury. On a Comeer 64, the 1541 drive wasn't just a peripheral. It was practically another computer with its own 6502 processor inside. My very first home computer, and it's the last thing anybody ever had to buy for me was a Commodore 64, complete with a 1541 disc drive. Unfortunately, I worked it so hard that the plastic cover melted, something the early units were a bit prone to doing. Yet, for all the heat and drama, it ran on a serial bus that was famously slow, which meant loading from discs still gave you enough time to contemplate your life choices. When fast loaders came along, they felt like discovering warp drive. But that slowness also taught you something that modern systems often hide. IO matters.

[00:06:20]Waiting on storage matters. The CPU can be sitting there bored out of its mind while the rest of the system dribbles bites through a straw. That lesson would come back later in databases, networks, cloud systems, and every application that mysteriously feels slow despite running on hardware powerful enough to simulate a small weather system. And then there was memory. A modern kid learning to program might start with a machine with 16 GB of RAM today and a browser tab that casually consumes more memory than an entire 1980s computer could actually address. Back then, 64K was the whole kingdom, and not all of it was yours. Some of it belong to basic, some to the screen, some to ROM space, some to IO, and some seem to disappear into little architectural potholes you only discovered when your program got big enough to fall into one of them.

[00:07:00]Before we got that first Commodore 64, my family was able to occasionally rent a Vic 20 from the public library for a week at a time. My first project was to write a Zork style adventure, but I should have paid closer attention to the boot prompts on the machine, which proudly proclaimed 3,583 basic bytes free. You quickly learned that strings cost memory. Arrays cost memory. Graphics cost memory. Everything cost memory. If your program grew too large, which mine did very early, the machine didn't just gently suggest optimizing your assets. It just simply stopped cooperating. And because there was no giant framework between you and the hardware, you started to understand the machine as a map. Certain addresses controlled the screen. Certain addresses controlled colors. Certain addresses talked to sound chips or joysticks or sprites. Peak and poke were not just basic commands. They were a side door into the machine's nervous system. On the Commodore 64, you could change the screen color by writing to a memory mapped register. And that was actually intoxicating. You typed the command, you hit a return, and the physical behavior of the machine changed before your eyes.

[00:08:00]Not through an API, not through an object model, not through some dependency injection framework that requires three config files and a sacrifice to your YAML gods, but by putting a number in a place where the hardware was looking for it. Better yet, if you did it in an assembly in a machine language monitor, it ran thousands of times faster than basic. So fast that the television's raster beam would only draw an inch or two before changing color. The CPU was faster than the television. And that is a powerful experience for a kid. It teaches you that software is not vapor. Software is electricity being bossed around by numbers. Somewhere under all the abstractions, the machine is still moving bits through registers, buses, memory cells, and devices. Once you learn that, you never quite trust a black box the same way again. You may still use the black box because civilization depends on abstractions, but part of your brain is always asking what it costs and why. The social side was just as strange. Today, programming is a cultural default. Kids have robotics clubs, coding camps, online courses, Raspberry Pies, Arduino kits, Minecraft mods, game engines, and entire communities dedicated to every possible niche. In 1980 Saskatchewan, you might be the only kid in your class who cared, or in my case, the entire elementary school. But by high school, I'd met a few kindred spirits who were also interested in the machines. So, you'd trade discs, you'd compare notes, you'd show off some little program that made a sprite move or made a tune that sounded almost, but not entirely like everybody was kung fu fighting. And when one of you actually figured something cool out, it would spread like contraband knowledge. Did you know that you can redefine characters? Did you know you can multiplex sprites? Did you know that this game stores the number of lives at this address? A lot of us learned by taking things apart like that. Not always legally, not always elegantly, but enthusiastically. You'd load a program, stop it if you could, list it if it wasn't protected, and try to understand how the trick worked. How do they scroll the screen? How do they make the sprites flicker less? How do they read the keyboard? How do they pack that much game into that little bit of memory? And that was not theft in the moral imagination of a 12-year-old prairie nerd. It was archaeology. BBS systems existed, but they were not the frictionless global brain that we have now. A modem was a portal, but it was also slow, expensive, and usually tied to the family phone line. At 300 baud, text appeared like somebody pretty much typing on the other end because essentially that's how slow it was.

[00:10:16]Long-distance charges were real, and if you tied up the phone too long, the system administrator you had to answer to was your mom. So pretty much all of your learning was local, deeply local, a manual, a magazine, a machine, and whatever stubbornness you could bring to the table. School could help, but only unevenly. A lot depended on whether there was a teacher who cared. And often that teacher was only a chapter ahead of the students. That's not an insult.

[00:10:37]That's heroism. Imagine being a math teacher in a small prairie school and suddenly you're expected to introduce students to microcomputers because somebody wheeled in a cart of machines and declared that the future had arrived. I was blessed that my mom had signed me up for the gifted program at the local Catholic high school. And by design or coincidence, I had a great computer science teacher attached to the program. He was the aptly named Mr. Bright, and he was likely only about 10 years older than his students. But he was that rare combination of enthusiast and educator that brought genuine interest and passion to the lecture. And he's able to spot the odd diamond in the rough amongst his students, which could be a gift because once you outran the lesson plan, you were in the wilderness otherwise. So he'd send us off into the weeds once a week with a new project like siving prime numbers. You learn that programming was not about being told the next step. It was about forming a model. If the loop runs 10 times, what changes each time? If the screen memory starts here, what happens when I write past the end row? If this variable is supposed to be five and it's actually zero, where did it get overwritten? Why does the program work until I add sound?

[00:11:35]Why does it crash only after the third level? Why does it behave differently when loaded from tape than when typed in fresh? These are systems questions. And the funny thing is you can ask the same thing today about Kubernetes, GPU drivers, distributed databases, or Windows kernel crashes. The nouns change, but the intellectual muscle is the same. You observe, you hypothesize, you isolate, you test, and you revise your model. And that's the real story here. Growing up in Saskatchewan in the 1980s made programming hard because everything was scarce, machines were scarce, documentation was scarce. The time on the computer was scarce, money was scarce, bandwidth was very scarce.

[00:12:09]But scarcity forced you into a relationship with a machine that was unusually direct. You could not just paste in an answer. You had to understand enough to actually proceed.

[00:12:18]Now, 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. There's nothing noble about a kid being unable to learn because the tools are too expensive or the information is too far away. But if you were lucky enough to get access and stubborn enough to stay with it, the environment trained you in a way that abundance often does not. It made you resourceful. It made you careful. It made you curious about what was underneath of everything. And it gave you a tolerance for frustration that turns out to be one of the most valuable traits in engineering because a lot of programming is actually frustration management. And as somebody with autism, that remains a growth area even for me. But it was formative in how I handle such things. That's not the brochure version, but it's true. The computer is a relentless mirror. It reflects your assumptions right back at you in the form of errors, crashes, blank screens, corrupted data, occasionally smoke, though hopefully not much smoke. Learning to program is learning not to take that personally.

[00:13:20]The bug is not proof that you're stupid.

[00:13:21]The bug is a clue. The machine is not angry. It's just being specific. A kid learning in Saskatchewan in the 1980s had to internalize that early. There was nobody coming to rescue you after every failed run. You could quit or you could be curious. And 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. Today, the barriers are lower. And that's wonderful. A kid in a small town can now download worldclass tools for free, watch lectures from top universities, ask questions in communities, run Linux in a VM, build a game in Unity, flash a microcontroller, train a neural network, and publish an app without ever seeing the inside of a computer store. That's astonishing. I would not trade that away. But the danger of abundance is that it can let you move forward without understanding. You can assemble software out of packages that you don't understand, deploy it to an infrastructure you don't understand, debug it by searching air messages you don't understand, and still get something that sort of works until it doesn't. And when it doesn't, then you need the old skills. You need the prairie skills. You need the ability to sit alone with a problem, build a model, and grind your way towards the truth. So the lesson from growing up as a wouldbe programmer in the 80s in Saskatchewan is not that everybody should suffer through cassette tapes and line numbered basic.

[00:14:34]The lesson is that constraints teach taste. They teach respect for the machine. They teach you that memory is real, time is real, IO is real, and complexity always sends an invoice. They teach you that documentation matters because somebody out there is trying to learn from it with no other help. They teach you that air messages should be useful because sometimes an air message is the only teacher in the room. And maybe most importantly, they teach you that you don't need permission to learn.

[00:14:58]You don't need a perfect lab. You don't need the newest machine. You don't need a polished curriculum. You need a prompt, a problem, and enough stubborn curiosity to just keep asking why. That was true on a frozen prairie in 1983, and it's true now. Even if the prompt is in VS Code, and the machine has more RAM than the main frames that we used to fantasize about. The old computers were limited, but they were honest. They invited you in. They exposed their machinery. They made you meet them halfway. And for a certain kind of kid in a certain kind of place, that blinking cursor was not just a place to type. It was a door. If you found today's episode interesting or entertaining, remember that I'm mostly in this for the subs and likes. So, I'd be honored if you consider leaving me one of each before you go today. If you have comments or questions, please leave them here in the comments section. We go through them and then every Friday, we answer the best viewer comments and questions on a shop talk episode on Dave's Attic every Friday. Check it out and give it a subscription there if you turn out to like one. Thanks. In the meantime, and in between time, hope to see you next time right here in Dave's Garage.

[00:15:56]>> Do it, Lynn. Do it. Do it.