A week ago I got a PR comment on a graph feature I was building. The tooltip always sat to the right of the cursor, so when you moved to the top-right corner of the graph, it covered the exact data you were pointing at.
My boss and I didn’t agree on how to fix it. Then he said something that stuck with me: “we make software for doctors, not gamers.”
But the fix I landed on came straight from thinking about how my favorite games would solve it. When the tooltip hits the right edge, it flips to the left of the cursor so it never hides what you’re looking at. Nothing fancy. Just an instinct about not getting in the player’s way.
I came to web development from game development, so instincts like that one come for free. I don’t usually notice them. Not until last Thursday.
For the third year running, I gave a guest lecture at my old university about how to build games the way you would in a game jam. And while I was revising it, a new thought hit me: the developers who’d benefit most from that lecture are the ones who never show up. The backend people, the data folks, the embedded crowd. The ones who’ve never given games a serious chance.
The thing no one you love can see
But I’m not really here to talk about instincts. That’s a bonus, and I’ll get to it.
The real reason is simpler than that. Think about the last time you tried to show your work to someone you love. “I built a data pipeline.” “I write drivers.” “I maintain an internal API.” You watch their eyes glaze over. It’s not that they don’t care about you. They just have no door in. You can’t hand them the thing and watch them use it.
A game is different. A game is something anyone can pick up. Your mom can play it. Your partner can play it. Your kids can play it. Your friends who have no idea what a compiler is can play it, and then tell you the boss was too hard.
That’s the part I miss most, coming from games. The work I do now is good work, but it lives behind a login on software most people will never touch. A game you can just hand to someone.
You already know how to do this
I know what you’re thinking. “I’ve never made a game. I wouldn’t know where to start.”
But a game engine is a pile of the exact problems you already solve. Rendering, physics, memory budgets, systems that other people tune without touching your code. The person who writes drivers is the person who’ll understand a frame budget. The data engineer already thinks in pipelines and state. The embedded developer has spent a career doing a lot with almost nothing, which is the whole game when you have 48 hours and no art. And if anyone’s showing up with a hand-soldered physical controller for their game, it’s them.
You’re not starting from zero. You’re pointing skills you already have at a target that happens to be fun.
That’s not a hypothetical. My first jam was the GMTK Game Jam back in 2022, on a team of mostly fullstack developers like me, plus some artists. Not a single game developer among us. So we built with what we knew: Cheating with a Mimic is a React app. It placed 1538th out of 6013 entries, on ratings from 28 strangers that ran the full range from five stars to one. Four years later it’s still sitting on itch.io, and anyone with a browser can play it.
The bonus: it makes your real work better
Now the instincts. Remember the tooltip.
In a game jam you’re forced to think about things most software lets you ignore. At a jam a couple of years back, our game had a day and night cycle as a core mechanic. We could have shown the time with a number in the corner. Instead we slowly dimmed the whole screen, so you felt the day slipping away instead of reading it off a clock.
That’s the same instinct as the tooltip, and it has a name once you see it: design the feedback loop, and show state instead of just reporting it.
And that one generalizes way past games. A data pipeline that tells you where it’s stuck beats one that just exits with code 1. A boot sequence that blinks out its status beats one that goes dark and makes you guess. The jam version of this is “teach the player with almost no words,” which is the same problem as onboarding anyone to anything you build.
So why a jam, and not just “make a game”
Because a jam is the lowest-stakes version there is. It’s short, the scope is capped for you, and unlike the work that never ships at your day job, it’s done at the end. You walk away with a thing.
“But I don’t have a free 48 hours.” Fair. And you don’t need them. Jams come in every shape: the 48-hour sprints like the Global Game Jam, longer ones like the Godot Wild Jam that give you about 9 days, and plenty that run fully async over a week or two. itch.io keeps a running calendar of them. Pick one that fits your life, not the other way around.
If you want somewhere to start, the GMTK Game Jam is three days away as I write this. It’s one of the biggest jams on itch.io, big enough that we’ve crashed their servers a few years running, and I’ll be in it too. Consider this your invitation. And if it’s already over by the time you find this, that calendar above never runs dry.
Do it once. That’s all I’m asking.
Go build something they can play
You didn’t get into this to build things no one you love will ever see. It just kind of happened. The interesting problems were behind the login, in the pipeline, under the hood.
A game jam is a weekend, or whatever shape of time you picked, to build something on the other side of that. Something you can hand to your kid, or your mom, or the friend who still thinks you “do computers,” and just watch them play.
The boss will probably be too hard. They’ll tell you. That’s the best part.