It's pretty common for people, upon hearing that I work in game development, to react along the lines of "wow, cool! What a great job!" And this is a difficult problem: they are both right and wrong.
I say "I make video games" and most people, sadly enough, hear "I play games all day." I do not understand where this ridiculous untruth originates, but it's deeply entrenched in popular culture for some reason. (Personally, I blame those abominable late-night TV ads for crap diploma mills - you know of what I speak.)
I love my job, but not for the reasons you think. You really don't want to be a game developer. I'm very cautious about showing enthusiasm for my job (hence my all-too-familiar half-lie "it's not really as interesting as it sounds"), not because I lack that enthusiasm, but because it's too easy for others to misinterpret it. Maybe we need a superhero mascot for game developers.
So why do I do this job?
About a week ago, someone asked why we make games. There are a lot of varied answers in there, and they all reveal interesting things about what drives people and basic human needs and instincts. There's ample material in that short thread for many long pages of philosophical exposition.
I dropped in and posted a short, cryptic, and possibly completely worthless answer; at the time I didn't really feel like expanding on it, but now I think the time has come to dig into what I really meant.
Quote: Because it's hard.
- Some dumb schmuck
It was an admittedly oblique reference to one of my favorite speeches:
Quote: We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not only because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.
- John F. Kennedy
What happens when it isn't hard enough?
I actually started my current game development job part-time at the same time as I started a 9-to-5 day job. The day job completely sucked, and it was a huge weight off my shoulders when I finally quit and went into games full time.
It took quite a while for my old position at that job to get filled, but it finally was filled a couple of months back. Every now and then I still get offers to come back and work there.
As flattering as those offers are, I keep turning them down. It's certainly not because the deal isn't good; there's a sickeningly fat chunk of cash at stake. Unfortunately, I'm one of those rare and annoying people who isn't motivated by money.
The other day I got to thinking: if they offered the ridiculous salary, and put me in a position of authority to fix all of the cultural problems, would I go back? If I could systematically change all of the things that had driven me crazy and eventually convinced me to leave, would I do it?
I have to admit it wasn't as easy of a question to answer as I thought. But eventually I arrived back at the same old conclusion: no, I wouldn't do it. The thought process was important, though, because it highlighted a very crucial fact.
The main problem with that job wasn't the terribly dysfunctional culture or the oppressive environment. The main problem was that the business ran out of good problems to solve.
By the time I left, I'd tackled almost every major interesting thing that would ever need to be done with the product we produced. There may be two or three more innovative and exciting things to do that might crop up in the future, but there's not enough to make a job out of them. All the problems left were trivial, maintenance type work - retreading ground I'd been over a dozen times.
The bottom line is that a fat paycheck and a lot of power are not sufficient incentive for me to do a boring job all day.
What exactly is "hard" about it?
Game development is in a state of constant movement. The technology is always changing. Every time your team puts out a title, there's a major new set of technology on the horizon - and you'll have to target that technology for your next title. Life in the industry is a constant tail-chasing spiral; game developers want better hardware, hardware developers create it, game developers learn it and push it to the limits, and then start dreaming about the next round of improvements.
In this business, there's almost always a new problem, or at least a familiar problem that has to be solved under new constraints. Once you solve all the big problems, you ship the game, maybe deploy a few patches, and then start the whole deal again.
Each iteration is different, because the product is different. Very few businesses can stay stable by changing their primary product every 3 years; for game developers, especially small independent studios, it's vital. The scenery changes completely after every project: new goals, new technology, new constraints.
This leads to an interesting situation. A lot of the problems that I solve on a day-to-day basis aren't really novel; they've been solved before. But in games, it isn't always possible to use a general solution. There's always some tailoring required to make a solution fit your context, and your specific needs. Even when we can use pre-built solutions, there's some work to be done in getting them to interface with the rest of our stuff.
Those problems are exciting because they're familiar, so they're comfortable, like well-worn shoes. You know what works, what doesn't, what you've tried before, and what you wished you could have done last time. They're an opportunity to refine and improve on what already exists, but they can be devilishly challenging when the rules have changed: last time you solved this problem, you needed to minimize the amount of memory used. This time, minimize the time it takes to run. Oh, and it has to be thread-safe and portable to four platforms and three compilers.
Sometimes there really are totally new problems. Those are exciting precisely because they're new; you get to enjoy the feeling of striking off into unknown territory. (I've often pondered buying a coon-skin cap for those occasions...) At the same time, they're a bit scary, because you know you can't rely on anyone else's expertise to help if you get stuck - everyone else is exploring, too.
The net result is that it's impossible to be bored. Virtually everything stretches you and demands your best. It's constantly challenging, and there's always a little niggling fear that I might not be able to hack it. And then, when you do hack it and ship a title, it's the most incredible feeling in the world.
Because It's Hard.
I love my job because it's hard. There has never been a period of my life when I have been so consistently taxed to the limit of my abilities, stamina, and focus. As a direct consequence, I've never had a better opportunity to expand and grow.
Solving problems is endlessly fascinating for me. Overcoming a huge challenge has illegal-drug-like effects. I find tremendous satisfaction in clean, elegant solutions.
But just solving easy problems isn't the same. Anyone can walk up a hill, but summiting Everest is a vastly bigger rush. Bigger problems offer much bigger rewards when we conquer them, and programming is no exception to this. The harder the problem, the more fun I'm having - and don't let yourself be fooled by the fact that I'm ripping out fistfuls of hair and screaming things that would make sailors blush. I may look pissed off, but I couldn't be happier.
There's a long running debate about whether or not programming is an art form. I think the answer is yes and no - it depends on the programmer, not on the programming. There are programmers whose entire goal is "get it to work" - and they can do a decent job of this. They're certainly programming, but it's utilitarian; the point is to solve a problem and nothing more.
There is another perspective though, where "working" isn't a goal but simply one of many requirements. Make it work, make it clean, make it elegant, make it maintainable, make it beautiful. Those are the programmers who practice an art form and not a bland, mechanical process of commanding a mindless machine.
Good art is hard, and good programming is art; it should come as no surprise that good programming is really, in fact, pretty hard. Hard problems, as we've just seen, are very rewarding to solve.
But there's more than just the surge of endorphins and assorted happy-chemicals in the brain; there's more than the "satisfaction in a job well done" (vomit); there's more than simply knowing that one has accomplished something significant.
The most priceless treasure of working on hard problems is that it might actually demand more of us than we can offer, that we might be forced to increase ourselves to meet the challenge.
Kudos to you!