Being the only programmer on a fifteen-person team
What that actually requires, what breaks first, and why the answer is mostly about other people.
For long stretches of a two-year production I was the only programmer on a team of about fifteen. Artists, designers, writers, audio – and me. I want to describe what that job actually is, because it is not the job it sounds like.
It sounds like a lot of typing. It is not. The constraint is not how much code you can write. It is that you are the only person who can unblock fourteen others, and every hour spent unblocking someone is an hour not spent on the thing only you can do. Left alone, that arithmetic eats the entire role. You become a support desk with a compiler.
So the actual job, the one that decides whether the project ships, is this: systematically make people not need you.
What that looks like in practice
The single most valuable thing I built on that project was not 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, these upgrades.”
It is about a thousand lines and it contains no gameplay whatsoever. It exists because the game had 119 scenes, and without it, testing any one of them required me. With it, a designer could open any scene and be playing in the right state in thirty seconds. That tool is the reason the game was testable, and a game that is not testable does not get finished regardless of how good its code is.
That is the pattern. Every time someone has to ask you to see their own work, that is a tool you have not built yet.
What breaks first
Not the code. The ability to test.
Failure looks like this: the project gets big, setting up any given state requires knowledge only you have, so nobody else exercises the game, so bugs are only found by you, so your queue grows, so you have less time to build the tools that would fix it. It is a spiral and it is very hard to reverse late.
The second thing to break is the content pipeline. On a large project the asset bundling configuration is fragile: bundles break, assets silently duplicate into several at once, references vanish after a bad merge. Every one of those is build-breaking and every one lands on you. I ended up writing several thousand lines of editor tooling for that alone – backup, validation, restore, duplicate detection – and it was worth it the first time it turned a lost day into five minutes.
What to protect
If you are the only engineer, two systems will decide whether the last three months are calm or awful, and both are unglamorous.
The save system, because it touches every other system, and it fails in front of the player after twenty hours of their time. Build it version-tolerant from the first day. Assume you will ship a patch, assume that patch changes data, and make sure it does not invalidate what players already have.
The content architecture, because it is where a large game either fits in memory or does not, and it is the hardest thing to retrofit.
Everything else can be fixed late. Those two cannot.
An honest caveat
I was not literally the only person who ever committed code to that project. Nine people did, over its life. But for most of production the day-to-day technical surface was mine, and the effects above are what that produces. If you are looking at a similar role, the thing to plan for is not the volume of work. It is the interruption.