It's not about technology for its own sake. It's about being able to implement your own ideas.

Newest Entry
Complete Archives
Atom Feed

I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage. Since 1999 one of those tools has been Erlang.

james.hague @ google mail

Where are the comments?

The Most Important Decisions are Non-Technical

I occasionally get puzzled questions about a parenthetical remark I made in 2010: that I no longer program for a living. It's true. I haven't been a full-time programmer since 2003. The short version of these questions is "Why?" The longer version is "Wait, you've got a super technical programming blog and you seem to know all this stuff, but you don't want to work as a programmer?"

The answer to both of these is that I realized that the most important decisions are non-technical. That's a bare and bold statement, so let me explain.

In the summer of 1993, I answered a newspaper ad looking for a "6502 hacker" (which I thought was amusing; the Pentium was released that same year) and got a job with a small company near Seattle writing Super Nintendo games. I had done game development prior to that, but it was me working by myself in my parents' living room.

The first SNES game I worked on was a Tarzan-themed platformer authorized by the estate of Edgar Rice Burroughs (it had no connection to the Disney movie, which was still six years in the future). I had fun working out ways of getting tropical fish to move in schools and creating behaviors for jungle animals like monkeys and birds. It was a great place to work, with the ten or so console programmers all sharing one big space.

The only problem was that the game was clearly going to be awful. It was a jumble of platformer clichés, and it wasn't fun. All the code tweaking and optimization and monkey behavior improvements weren't going to change that. To truly fix it required a project-level rethink of why were building it in the first place. As a "6502 hacker" I wasn't in a position to make those decisions.

While it's fun to discuss whether an application should be implemented in Ruby or Clojure, to write beautiful and succinct code, to see how far purely functional programming can be taken, these are all secondary to defining the user experience, to designing a comfortable interface, to keeping things simple and understandable, to making sure you're building something that's actually usable by the people you're designing it for. Those are more important decisions.

Whatever happened to that Tarzan game? Even though it had been previewed in Nintendo Power, the publisher wisely chose to pay for the year of development and shelve the finished project.