I sometimes refer to myself as an “ex-programmer,” but in reality, it’s hard to get away from coding as long as you’re spending your days near code. It’s not so much an addiction as an occupational hazard; sometimes, rather than waiting for your overworked engineers to make that one little tweak you need made, it’s easier just to do it yourself. But that just makes you a little more impatient the next time something comes up, and you write more and more of your own code until one day the engineers look up and notice that you’ve grafted an entire framework for AI tuning onto the side of their code base. And then they shrug and say, “just make sure you don’t break the build.”

So I spend a lot of my work days doing both design and programming, which is fine, except that the two disciplines are very different. In fact, they’re downright contradictory at times, which leads to a lot of conversations like this between some of the voices in my head:


Programmer Josh: We are in the business of making systems that are consistent, regular, testable, maintainable, and stable.

Designer Josh: And boring, apparently. The business that we are actually in is that of making magic boxes that surprise, delight, and entertain people.

P.J.: Don’t bring your hippy-dippy talk of “magic boxes” in here. Every one-off feature or special case that you introduce makes things that much harder to keep track of and fix.

D.J.: That may be, but I’d rather deal with a difficult system than a bored player.

P.J.: What about consistency? Doesn’t a strong pattern make the game more learnable?

D.J.: There’s a difference between being learnable and being monotonous. And don’t forget that games are all about repetition. What seems like a one-off when you’re developing the system will still be encountered by the player dozens, if not hundreds of times.

P.J.: But… how can you stand to look at all of those stray if() statements? The mysterious timers? The dodgy event interceptors? The HARD-CODED VALUES?! *breaks down weeping*

D.J.: There, there. It’ll be all right.


In the end, Designer Josh almost always wins, because when you boil it all down, the programmer’s job is to advocate for the safety of the system, while the designer’s job is to advocate for the richness of the player’s experience, and the player always comes first. When I was a programmer, I called this “scope creep,” but now that I’m an ex-programmer, I call it “making the product not suck.”

Of course, both Designer Josh and Programmer Josh usually end up getting overruled by Schedule-Watcher Josh, who notices how little time we have left before Alpha and starts cutting scope like there’s no tomorrow. But that’s another conversation altogether.