How I learned to code; The good, the bad, and the explosions

I didn't have a console growing up. No PS4, no Xbox — the games other kids talked about at lunch were games I watched other people play on YouTube. I'd sit there looking at whatever gorgeous thing was on screen, some triple-A world with real lighting and weight to it,¹ and then I'd look at my own screen, where the state of the art was a handful of blocky sprites I'd wired together in Scratch.

You want what you don't have. That gap — the polished world I could only watch, and the crude one I could actually touch — is where all of this starts.

So I did the next best thing to playing those games. I took apart the ones I could reach.

Entering through the back door

My first real programming wasn't building. It was breaking.

The games I could play were Scratch projects and Cool Math Games — World's Longest Platformer on one, Fireboy and Watergirl on the other — and I wasn't always good at them. The first one I remember properly hacking was World's Longest Platformer, a wall of a project, a hundred-something stages, hugely popular on Scratch at the time. I was stuck somewhere, and then I noticed: in the editor, I could just grab my own sprite and drag it wherever I wanted.

That was step one. Step two was wanting to not have to do it by hand.

Scratch is genuinely good at organizing itself into categories, so I went hunting. Movement, go to, mouse pointer — I wired up a key press to teleport my sprite to wherever my cursor was, and suddenly I could skip any obstacle in the game by clicking. From there it was infinite ammo in a shooter, air jumps in a platformer, whatever a given game was withholding from me. Small buffs, slid into other people's code.

None of these were hard. That's the honest part. The satisfaction wasn't "I built something clever" — it was what the hack unlocked. You give yourself infinite ammo and suddenly you're not struggling anymore, you're mowing everything down. The code was just the cheat code.

But it taught me something before I could have named it: a game is a system, and a system has a seam you can open. I was inside the machine before I ever tried to build one.

The first thing that was actually mine

The real moment — the one I'd call the beginning, if I had to point at a single frame — came when I stopped editing other people's games and made my own move correctly.

I was in sixth grade, and I wanted a shooter mechanic — a separate thing from the platformers I was also making, though both ended up needing the same math. I wanted bullets that flew off in whatever direction I aimed. Scratch makes it easy to move a thing radially — point in a direction and go — but I wanted real motion in x and y, so I could treat the two axes independently and hang acceleration off the vertical one. Getting from "this is the direction I'm aiming" to "this is how much x and how much y" is exactly what sine and cosine are for. I wouldn't formally see trigonometry in geometry class for another two years.

So I did it on paper. Worked out the components by hand, dragged the values into Scratch, and clicked the button. And the thing moved — traveled in the direction I'd actually aimed, gained speed, slowed, arced back down under acceleration, drifted sideways when I held both keys. Exactly the way I'd calculated it would.

Nobody was there for that. I didn't run to show anyone — not because it didn't land, but because I was in the zone, and in the zone you don't stop to celebrate.² The thing worked, and it was only step one of what I was actually building, so I kept going. The celebrating comes later, once I've surfaced and can look back at what got done.

What I was building grew into a game called Elements ↗, which is somehow still playable³. Once I had the physics, I copied wall-jumping off the platformers I admired — the trick was less the jump and more getting the game to know you were touching a wall, so I hand-rolled the same kind of bounding boxes you'd get for free in a real engine: a floor-collision block, wall-collision blocks. Then swimming, where you'd slowly sink and kick back up. Hazards that killed you. Screen-to-screen transitions like old Mario, where you walk off one edge and the next room loads in.

There was a sixth-grade class project I built on top of all this — a little world set in the Falkland Islands, with enemy AIs that fought back and projectiles that bounced off boxes, which was a genuine pain to get right with the trig I only half-knew. It scored full marks. It wasn't actually hard. But it was mine, and it worked, and that was the whole reward.

Where the systems-thinking actually came from

Here's the part that surprises people: the instinct to hold a whole system in my head didn't come from code. It came from books.

Not having games meant most of my entertainment was reading, and I read like it was a job — somewhere around a hundred books a year. One library haul, I checked out forty Geronimo Stilton books at once. My librarian gave me a look. It took me two weeks; I read every single one.

The arc went Captain Underpants — the first book with a real narrative shape that grabbed me — then Harry Potter, which was the first series I loved enough to write fanfiction about in my head at night, lying awake extending the world. Then it snowballed: Keeper of the Lost Cities on a friend's recommendation, all of Percy Jackson, and from there straight into the source material — Homer, Hesiod, the Poetic Edda, learning my way around the Mahabharata. I was doing comparative mythology as a teenager without knowing that's what it was called.

That's the skill. Not "reading is good for you," but the specific muscle of entering a built world, holding all of its moving parts at once, and feeling where a new piece would or wouldn't belong. It built taste — a sense of what holds together and what doesn't — years before I had a codebase to apply it to. And it made me comfortable with a whole world sitting in my head as a single object, which is exactly what you need when a project has a hundred parts and none of them are built yet.

Taking it too far, on purpose

I started with actual programming languages fairly late by CS-major standards. Tenth grade, a high-school CS 101, Java in BlueJ, drawing triangles. Easy stuff.

But I already had the disease. When the class asked for a game, most people made a side-scrolling story. I made some physics-based thing that went well past the assignment, because the moment I had a new tool in my hands I wanted to run it all the way to the wall. That's just what happened every time. AP CS came next, and the basics were basics — the interesting question was always how far past them can I get.

The furthest I ever tried to get was an open-world 3D game.

I wanted to build the thing I'd never been allowed to play as a kid. I applied for an independent study, got it approved as an extra course, and started. And I want to be clear about the order I worked in, because it's the whole point: I didn't start with "how does my character jump." I started with where does this character go, and what does it mean.

So I built the pantheon first. The world was called Cavea, and I wrote its gods before I wrote a line of code: Galena, the first goddess, created by the Origins to keep the world in balance and spectacularly bad at her job; Thurn, the god of Power, running his empire on a balance that only looked like peace; Zaganthra, the exiled demon king too proud to ally with anyone who could actually help him. There was a whole history — millennia of it — of Heavenly Wars and empires and a species called the Depraved born out of leaked divine energy.

And then there was how the actual game started, which I'm including because it tells you everything about the register I was working in. A god named Change has her VR gaming setup destroyed, gets annoyed, and pesters a higher power called Eternity to go find out what happened. Eternity, rather than look into it directly, grabs a random drunk nobody living out in the middle of nowhere — chosen specifically because he's far from society and its state religion — and ropes him into the whole cosmic errand. When the guy tries to get out of it, Eternity keeps him in line by killing and reviving him a "few" times until he stops arguing. That's your protagonist: a man dragged onto an epic he never wanted, by a bureaucratic god, because someone's game console broke.

The rest was scaffolding on top of that: story forks, a reputation system, NPCs I hoped one day to drive with AI. Underneath all of it, one question the whole game was secretly about: who's actually in control? The protagonist starts as the most controlled being imaginable — killed and revived whenever Eternity finds it convenient — and the arc is him throwing off every hand on the strings, one at a time. By the end of act one he's betrayed by the gods and watches as his whole world falls to pieces. And by the ending of act two as our protagonist begins slaying the very gods he swore to defend: the character breaks free of your control, the player's, and you sit there and watch him walk off to kill the gods of change and eternity, unmaking the world. I mapped the entire thing out in Lucidchart — eleven epochs, every event, every interaction, every quest, the philosophy behind it — and every word of it was written by hand. There was no model to lean on; there wasn't one worth leaning on yet.

I designed around a hundred weapons, each with its own written backstory, tiered from a Sword of Light carried by a minor god down to a fire-hardened stick someone carved off a branch.⁴ I picked up Blender and modeled maybe ten of them. They looked pretty cool.

And that's about as far as it got. Blender was the wall I didn't get over.

Scope explosion, not scope creep

The standard advice for a beginner is: start small, ship something tiny, level up slowly. That was never how I worked. For me it wasn't scope creep — a small thing quietly growing — it was scope explosion. I started with the cathedral and worked backward toward whether I could pour the foundation.

The mechanism, once I could see it, was always a tree. Start from the root — what do I want this to become — then the branch below it, what has to happen for that, then break each of those into systems: a damage system, a reputation system. Then decompose those further, and further, until you hit something you can actually type. The root was never the code. The code was the last, thinnest layer of leaves.

It wasn't only games, either. Near the end of high school, when AI was suddenly new and I half-wanted a project and half-wanted a college-application shiny, I built something I called TLDR: a browser extension that let you select any element on a page and summarize it, with a streaming mode that would chunk an entire page, ship the HTML to a backend, get it summarized, and repopulate it in place. I lifted the skeleton straight from uBlock — it already had the element-selection machinery — rewired the routing, and swapped in my own behavior. I wasn't good enough yet to enforce a schema on the model's output, so my actual strategy was to feed it HTML and hope the same shape came back. I never got it onto the extension store; college apps ate the runway and I shelved it.

But even shelved, the thing I remember isn't the code. It's that I sat down with a stack of sticky notes and drew out the entire user flow — what you'd see when you opened it, where the buttons went, whether you'd pay for the service or bring your own API key, how it would remember what you'd already summarized, how you'd move from one state to the next. I was writing user stories before I knew "user story" was a term someone had already invented. Same instinct as the game, pointed at a different domain: build the whole world first, then figure out how to get there.

Here's the frustrating truth about all of it: none of these were finishable by someone who had just learned loops, conditionals, and System.out.println. The gap between what I could imagine and what I could execute alone was just too wide. And the tools weren't there to close it — this was the ChatGPT-3.5 era, when the model was still kind of dumb, couldn't reliably add two numbers, and was best used for writing stupid stories.

The tools have caught up since — but it's worth being honest about how much. TLDR? That's a weekend now. But Cavea was never a weekend, and it was never going to be. That was a scope nuke — a real open-world game is a year of dedicated work at minimum, probably several, on top of the decade it takes to get genuinely good at 3D modeling. Think about how long a studio takes to ship a God of War or a Devil May Cry, then hand the whole thing to one high schooler. It was destined to fail. The point was never that I could have shipped it if I'd been born a few years later. The point is that the tools were only a few years away — and even a few years was enough to sit on the wrong side of the line.

Where the instinct sits now

These days it's roughly fifty-fifty. I've gotten capable enough to actually land some of the big-bang ideas — that's part of what Kirimana → and Pyobfuscate → are. But the other half is knowing how to rein it in: I no longer explode my own scope toward things I flatly cannot do. There are still ideas I wish I could chase where the honest move is to put the lid on it and go do the achievable thing instead. And now there's the added weight of thinking about a career, which quietly changes which cathedrals are even worth breaking ground on.

But I want to end on the thing I feel most strongly, because it runs against the obvious lesson.

I don't regret the scope explosions. Not one of them.

I know the tidy version of this story ends with "and that's why you should start small and finish things." Plenty of people look back and wish they'd built a few modest, completable projects — the kind that actually go on a college application, the kind you can point at. I didn't have those. What I had were Schrödinger's projects: things that existed right up until you opened the box and looked. Nothing you could put on a resume. Everything I actually cared about was three sizes too big and unfinished.

And it didn't matter, because the finishing was never where the value was. Reaching for the open world I couldn't build is what taught me to see a system as a whole instead of a pile of separate threads — to start from the root and the meaning instead of the jump button. That's the thing that survived. The half-modeled weapons and the Lucidchart lore and the extension that never shipped were never the point. They were just where I learned to think.

I used to only build things I couldn't finish. I'd do it exactly the same way again.