Being the main programmer on a fifteen-person team - Writing

I joined Memoreum in 2022, and until its final year I was the only programmer on a team of about fifteen apart from our audio programmer. Artists, designers, writers, audio - and me. I want to describe what that job is, because it isn’t the one it sounds like.

It sounds like a lot of typing. Mostly it’s that you’re the only person who can unblock everyone else, and every hour spent unblocking someone is an hour not spent on the work only you can do. Left alone, that arithmetic eats the role. So a large part of the job becomes making people not need you.

What that looks like in practice

One of the most useful things I built on that project wasn’t a gameplay system. It was a per-scene override that let a designer say “in this test scene, start the player with these tools, this weapon, this much ammunition”.

It’s about a thousand lines and contains no gameplay at all. It exists because the game had 119 scenes, and without it, testing any one of them in the right state needed me. With it, a designer could open a scene and be playing in the right state straight away. A game that only one person can test properly is a game that gets finished slowly, however good its code is.

The pattern generalises, with a caveat. Every time someone has to ask you to see their own work, there’s probably a tool missing. But not every one is worth building; some requests come up twice in a project, and a quick answer is cheaper than a thousand lines.

What breaks first

Not the code. The ability to test.

As the project grows, setting up any given state starts to need knowledge only you have, so nobody else exercises the game, so bugs are only found by you, so your queue grows and the tools that would fix it never get built. It’s a spiral, and it’s much easier to prevent early than to reverse late.

The second thing to break is the content pipeline. On a large project the bundle configuration is fragile: bundles break, assets quietly end up duplicated in several at once, references go missing after a bad merge. Every one of those breaks the build and lands on you. I wrote several thousand lines of editor tooling for that alone - backup, validation, restore, duplicate detection - and the first time it turned a lost day into a few minutes it had paid for itself.

What to protect

Two systems decide whether the last months are calm or awful, and both are unglamorous.

The save system, because it touches every other system and fails in front of a player who has put twenty hours in. Make the format version-tolerant from early on, and assume you’ll ship a patch that changes data.

The content architecture, because it’s where a large game either fits in memory or doesn’t, and it’s the hardest thing to retrofit.

Most other things can be fixed late. Those two are much harder to.

What I’d tell someone starting that role

Expect the job to be less about the code you write than about how well everyone else can work around you. The tools that let a designer test a scene, the pipeline that stops a bad merge from breaking the build, the save format that survives a patch - none of them show up in a trailer, but they’re what kept a fifteen-person team moving with one programmer at the centre of it.

If I were doing it again, I’d build those things earlier, before the queue of requests made the case for them. And I’d spend more time explaining how the systems fit together, because every person who understands that a little better is one fewer question waiting for you.