"We Make Games!" Isn't Good Enough

The cat is out of the bag.

You've been in the industry for a few years and are feeling frustrated. You've jumped from one pot of scalding water to the next, searching for the perfect dream job. Every time you leave, your employer is shocked into a silent stupor. Or, maybe they’re afraid they’ll be emotional. Still, you have an inkling that they just don’t give a damn.

The people were keeping you there, the other guys and gals in the trenches right next to you battling to make the game “great”, resolve the final cert issues, and push the product out the door. But, one-by-one, they left, or you became too frustrated to keep your slipping grip on your keyboard. You just had to let go. Your internal “too much” meter was triggered and, inside, you were beginning to feel like a carved out pumpkin.

And... it’s dead.

I can only point to anecdotal evidence; but, from where I sit, as a game developer, I’ve seen a lot of my friends and former colleagues choosing one of two paths: to either go independent or leave games. The younger the developer, the more likely they are to follow one of those two paths. This is especially true of engineers.

I’ll get into why independence is appealing.

But, why leave games? In fact, let’s ask a simple question: why not enter games?

I teach a graduate course on game engine architecture. Most of the brilliant programmers I’ve encountered go off to work for either a small start up, or a megabeast of a software company. There are some huge motivators and deciding factors. I’ll get into them in a few moments. Keep reading.

Plumbers and pipes. 

When I say plumber, what comes to mind? Jeans slipping down revealing a crevice large enough to fit a sofa, perhaps? Definitely not an elegant individual with brilliance to spare and a motivated intelligence capable of slicing a man in twixt. No, certainly not.

Think about the engineers in your organization. Think about your interactions with them. Do you (or the other people at your company) treat them like plumbers? “Oh, it’s borked. Fix it.” Do you send them off to do tasks without thinking about how hard the tasks are, how important they are, etc. Are they full-time? Do they have a full-time say in what they do? Or, are they thumbing hair out of a u-bend constantly? When was the last time you genuinely sat them down and asked what they wanted to do?

Software engineers aren’t plumbers.

Look at the open source community. To some degree, the existence of open source is a means of venting frustration -- frustration at not having the creative freedom to build. It takes bravery and curiosity to create. Are you using your engineer’s creativity to its fullest? Or, are you ordering them around like a plumber you’d call in to fix an overflowing toilet?

Developer-centric companies have been easily skimming the best programmers from the software world. Why? How do they do this? Conversely, small companies seem to have the same ineffable ability to find talented, capable programmers and hold them for some time? How? How can that translate to other organizations?

Hiring ain’t easy.

I’ve been on both sides of the hiring equation. I’ve said no to companies. Why? Well, their environments didn’t appeal to me, or I met managers I didn’t like. Worse, the office space might have been atrocious. Please read Peopleware. Please. How much did these companies invest in attempting to hire me? Well, there’s the time they spent to do initial interviews and subsequent interviews -- precious moments taken from developers’ schedules -- and the cash they threw to agencies and ads. There’s a deep cost to trying to hire someone. If they want me, and I say no, that’s a huge loss.

On the flip side, it’s very difficult to find the exact person you want. You need to find someone that will work within the constraints of your company (money, work attire, social environment, projects, etc.) and have the ability to succeed at the necessary tasks. Most importantly, you probably need them ASAP.

We aren’t cars.

When you buy a car, you haggle. It’s worth a shot, right? That car is still going to have the same features and work the same way, regardless of how much cash you manage to get the dealership to part with.

Why are you haggling with your developers? Why are you holding back in giving them the best “experience” ever?

A lower paid developer with less benefits is not the same developer as one that isn’t worrying about salary, isn’t worrying about benefits, and isn’t worrying about any other external factors.

Caveat: I am not advocating paying more. Paying beyond a certain threshold does not motivate people to do more work. Rather, I’m saying the “threshold” to be happy has to be met. If you don’t know the threshold, aim high! What’s the worst that happens? You’re overpaying a developer a few thousand dollars and he or she is happy?

If you’re not paying a developer enough, what’s the worst that happens? He or she leaves. That’s a severe consequence.

Sports teams actively recruit the best and the brightest. They appeal to them through nearly any means necessary. What are you doing to appeal to your engineers, designers, or artists? How’s your work environment? Crowded? Amply lit? What about benefits? Are they at a point where your devs simply won’t worry about them? How worried, in general, are your devs? About life? About work? About life-work?

A car can’t worry. A developer can. A developer that’s worried will not only under-perform, but seek avenues to alleviate that concern -- leaving.

We’re quiet. Get used to it.

Many developers are quiet about their needs. It just works that way. Then again, how actively are you inquiring into our happiness? How engaged are you in resolving our issues? Plumber? Plumber? Plumber anyone?

I’ve been told, “Well, you should’ve reminded us you wanted more money!” at a year review. I had joined the company with a verbal agreement that, if I’d performed well, they would match, within a year, a very high offer from another company. I was told I should have made them aware of the fact. Yet, I was hired to be an engineer. Should I also be a haggler, a business person, AND an engineer? As an engineer, engineering is my primary concern.

You worry about the rest.

“We make games!”

Moral of the story:

Are you trying to keep your developers at your office by saying that you make games? Do you believe that’s enough to hold them there?

Guess what? Other people make games, too!

And we can make games without you.

Most of us programmers were awe struck at some point in our early lives by some game. That’s why we’re in the industry. That’s why we love working on games.

Yet, if a programmer is being treated like a call-in plumber, to solve a problem without being truly invested, to cure a clog without having built the piping system, or without the proper motivating systems, how long will that plumber-programmer stay? How important is he or she to your operation?

“Millions of people will play this game!” There are millions, if not billions, of grommets in the world. Would I rather engineer a Porsche? Or a grommet?

“Freedom!”

Independence is, in and of itself, appealing. The forefathers of the United States saw this and utilized the concept to motivate a populace in rebellion against a much stronger foe. Game developers are, rapidly, realizing that we can strike out on our own and be moderately successful.

This is especially true of engineers. We have hard skills that are in demand and capable of crafting unique and appealing systems. We’re the fundamental linchpin in software. Without us, there would be no software!

With mobile booming, xbox allowing indies, and the PC reigniting through digital distribution, how are you going to keep us working on “your projects”? What’s to keep us there?

Sure, there’s security; but, that only goes so far, doesn’t it? Additionally, an engineer may stay to feel secure, surely, but are you getting the most out of him or her? Why are you hobbling your own developer? Engineers thrive on creating. When stifled, these individuals will not perform.

Developers, developers, developers.

As a developer, I have choices to make. Do I want to work for a company where I’m a plumber, constantly being told what to do? Where other people hold my project future in their hands? This is a very traditional model. It’s predominant. Engineers are given work to do, just like in school, with varied performance.

What happens when you unleash the inmates?

Ask Valve.

Developer-centric and start up almost need to be synonymous. In most start ups, the power distribution is broken evenly or slightly in-skew of the engineer. Why is this? Well, first, there are few cooks, few invested individuals. Secondly, in a software system on a small team, it’s nearly impossible to replace the engineers, right? Think about it, they own the code. They’re the only developer to ever touch it. They understand the in’s and out’s. How would you replace them? So, they typically have a good amount of control.

This control is appealing.

Additionally, there can be a good amount of celebration, right? Even for little features. “We have our first creature moving through the environment!!! BEERS!”

This feeds into:

Challenge --> Mastery --> Recognition.

In Summary

Well, that was a bit ranting; but, I hope you got the primary message. Engineers need to be looked at less as commodities and more as strong investments that the company is making. A good engineer can add huge amounts of value to a company; but, ask yourself, what value are you adding to that engineer and his or her life?

I guess, ask not what an engineer can do for your company, but what your company can do for an engineer.

Have a good weekend!

About the Author

Andrew Andreas Grapsas is a game programmer at Arkadium, Inc. developing facebook games. Previously, he was a gameplay and animations programmer at Kaos Studios|THQ, and intern systems programmer on Medal of Honor.

Andrew is actively writing and programming for various projects. You can read more at his blog aagrapsas.com. He promises to update it soon.

Follow Andrew on twitter!