I learned to code because of a hand-me-down PC and a book nobody expected me to read. I was ten. The PC was a beige tower that hummed like a small appliance and ran DOS. It came from a relative who’d upgraded, along with a box of cables, a dot-matrix printer with no ink, and a BASIC reference manual that was probably meant for the recycling bin.

I read the reference manual cover to cover.

Not because I was some prodigy. Because there was nothing else to do with this machine. No games came with it. No internet. No friends in the neighborhood had computers. It was a box that did nothing unless you told it what to do, and the book explained how to tell it. So obviously I read the whole thing.

The first program I wrote was the one from page one of the book. 10 PRINT "HELLO WORLD" / 20 GOTO 10. It filled the screen with HELLO WORLD until I hit Ctrl+Break, and I thought it was the most incredible thing I’d ever seen. A machine doing what I said. Over and over. Exactly as instructed.

I moved through the book methodically. Variables. INPUT statements. IF/THEN. FOR loops. GOSUB. I wrote little text adventure games in GWBASIC where you picked a direction and something happened. They were terrible. The parser was just nested IF statements checking exact string matches. Type “go north” and you’d move. Type “Go North” and you’d get “I DON’T UNDERSTAND.” I didn’t know what case-insensitive comparison was. I was ten. Cut me some slack.

Eventually I graduated to QBasic, which came with DOS 5. QBasic had SCREEN modes. Graphics! You could draw pixels! I made a game where a square moved around and collected other squares. It was Pac-Man if Pac-Man had been designed by someone who’d never seen Pac-Man and also couldn’t draw circles. Riveting gameplay.

Game dev was the spark. The thing that made programming feel like it mattered. You write code and a thing moves on screen. Cause and effect, instant feedback, dopamine. Every kid who learned to code in the 80s and 90s has this story. The specifics differ but the feeling is the same: I made the computer do a thing, and the thing was mine.

The Modem

The PC had a modem. 2400 baud, internal, sitting in an ISA slot. I didn’t know what it was for. The reference book didn’t cover modems. But there was a sticker on the front of the case with a phone number and the word “CompuServe,” and one day I figured out that the modem connected to the phone line and the phone line connected to… something.

AT commands. That’s what the modem spoke. ATZ to reset. ATDT followed by a phone number to dial. I found this out from a different book at the library, one about telecommunications that was meant for adults and used words I didn’t understand. But the commands were simple enough. Type ATDT and a number. The modem screams. Something screams back. Characters start appearing on screen.

I dialed the CompuServe number. The modem negotiated. A login prompt appeared. I didn’t have an account. I didn’t have a credit card. I was ten. But for about thirty seconds before it kicked me off, I saw text appearing on my screen that was coming from somewhere else. From a computer that wasn’t mine, in a building I’d never been to, connected by a phone wire and two modems screaming at each other at 2400 bits per second.

That was the moment. Not the QBasic games. Not HELLO WORLD. The moment I realized my computer could talk to other computers, and that there were protocols governing how they talked, and that if I understood those protocols I could make them do things. 🔥

Building a Telnet Client in GWBASIC

I’m not going to pretend this was elegant. It was GWBASIC. I was writing a telnet client in a language that didn’t have sockets, using a serial port library I barely understood, parsing raw bytes coming off a 2400 baud modem. Totally normal ten-year-old activities.

But that’s what I did. I found BBSes. Local ones first, numbers scrawled on photocopied lists that got passed around. You’d dial in, the sysop’s modem would answer, and you’d get a menu. Message boards. File downloads at speeds that made you plan your evening around a 200KB ZIP file. Door games. TradeWars 2002. Legend of the Red Dragon.

The BBS text used ANSI escape codes for color and cursor positioning. My terminal program needed to understand those. An ANSI escape sequence starts with ESC followed by [, then some numbers and a letter. ESC[31m means “switch to red text.” ESC[2J means “clear the screen.” ESC[10;20H means “move the cursor to row 10, column 20.”

I wrote a parser. In GWBASIC. It read bytes off the serial port, buffered them, watched for ESC characters, accumulated the escape sequence, and then executed the corresponding action. Color changes mapped to GWBASIC’s COLOR statement. Cursor moves mapped to LOCATE. Screen clears mapped to CLS.

It was, in retrospect, my first protocol implementation. I didn’t know the word “protocol” yet. I didn’t know I was implementing a state machine. I just knew that bytes came in a specific pattern and if I decoded that pattern correctly, the screen would look right. Accidental computer science is still computer science.

RFCs at Twelve

BBSes led to the internet. Not the web. The internet. Telnet, FTP, Gopher, IRC. By the time I had actual internet access through a local ISP, I already understood the concept of a client talking to a server over a text-based protocol. Telnet to a MUD was the same shape as dialing a BBS, just over TCP instead of a phone line.

I started reading RFCs. Not all of them (thank god). But when I wanted to understand how IRC worked, someone on a MUD told me to read RFC 1459. So I did. It was dry. It was precise. It told me exactly how IRC messages were structured: a prefix, a command, and parameters, separated by spaces, terminated by CR-LF. That’s it. The entire protocol fit in my head.

Once you can read an RFC, you can implement the protocol. Once you can implement the protocol, you can automate it. Once you can automate it, you can make it do things the protocol designers never intended.

This is the through-line of my entire career, and it started with ANSI codes on a 2400 baud modem.

MUDs and the Automation Instinct

MUDs were the thing that cemented it. Multi-User Dungeons: text-based multiplayer RPGs where the entire interface is lines of text scrolling up your screen. You type kill goblin and the server sends back combat messages. You type north and it describes the next room.

I played MUDs obsessively. And then I started scripting them. Because of course I did.

MUD clients had trigger systems: pattern matching on incoming text that could fire automatic responses. See “A goblin attacks you” in the output? Automatically send kill goblin. See “You are hungry”? Send eat bread. See “Goblin drops a gold coin”? Send get coin. It’s social engineering for game servers.

I wrote automation scripts for other players. Complex ones. Scripts that would path through a zone, kill every mob in order, loot the corpses, return to town, sell the loot, buy supplies, and start over. Scripts that tracked cooldown timers and resource management. Scripts that parsed combat messages to calculate damage-per-second and optimize gear loadouts.

These were bots. I was writing bots before I knew the word! And the core skill was always the same: read the protocol, understand the patterns, write code that responds to those patterns faster and more consistently than a human can.

Some players thought this was cheating. The MUD admins definitely thought this was cheating. But I wasn’t exploiting bugs. I was reading the output, understanding the structure, and responding programmatically. The protocol was text. The protocol was documented (implicitly, by the game’s own output). The automation was just… literacy, applied at machine speed. 😏

The Skill That Never Changes

I’m in my forties now. I build frontend systems, WebGL experiments, AI tooling, a MUD server of my own in TypeScript. The surface has changed completely. I write shaders instead of ANSI parsers. I wrangle WebGPU instead of serial ports. I implement RAG pipelines instead of MUD triggers.

But the underlying skill is identical. See a system. Read its protocol. Understand the data flow. Automate the interaction. Make it do things it wasn’t designed to do.

When I built the chat widget on this site, the process was the same as writing that GWBASIC telnet client. Understand the API (Groq, WebLLM). Understand the data format (JSON, SSE streams). Parse the incoming bytes. Render the output. The modem is gone. The baud rate is measured in gigabits now. The bytes still come in patterns, and the patterns still need parsing.

When I write MUD automation for EllyMUD, I’m doing exactly what I did at twelve, just in TypeScript instead of whatever ad-hoc scripting language zMUD used. Pattern match on server output. Trigger responses. Manage state. The game is mine this time, so nobody can ban me for it. 😈

Game dev was the initial spark. QBasic squares collecting other squares. But the thing that actually shaped me, the thing that turned “kid with a computer” into “person who builds things for a living,” was the modem. The discovery that computers could talk to each other. That the conversation followed rules. And that if you learned the rules, you owned the conversation.

I’ve been learning the rules ever since. The protocols got more complex. HTTP, WebSocket, WebRTC, gRPC. The parsers got more sophisticated. The automation got more ambitious. But the instinct is the same one I had at ten, staring at garbage characters on a screen and thinking: there’s a pattern in here, and if I find it, I can make this do anything. 🔥

That instinct doesn’t come from a CS degree or a bootcamp or a tutorial. It comes from a 2400 baud modem and a reference book nobody expected you to read.