Whining, and Tech Art

A recent Facebook discussion prompted some discussion about how many programmers (especially in games) have awful development environments. So many studios don’t how to properly use (and the benefits of) source control. We work with proprietary or handicapped tools because we work with some frankensteined engine where standard tools are helpless. We don’t practice techniques like TDD because our labyrinthine legacy codebases make it almost impossible to hook up properly. We don’t educate ourselves on modern literature, tools, and techniques, because we’re stuck with these sorry conditions on projects that last for several years at a time.

And this is why I’m a Tech Artist, and not a Tools Programmer, or Game Programmer. Because I want to be a whiny bitch and be able to fix what I whine about.

I wouldn’t be able to put up with the conditions described above. I know myself and I wouldn’t. I wouldn’t put up with it, so I’d whine, and alienate myself or burn out, and the scope of the changes are so drastic (this is an endemic cultural problem at many places), I wouldn’t get anything done. So I am a Tech Artist, I can operate outside of the fold, trying out new things, talk about about what’s broken, changing things, and demonstrating why and how they’re better.

Of course, there is a time to buck up and get down to making a game. Complaining, advocating, and causing change is good, but using all your skills and brute force to ship the best thing you can is important too.

But if you’re not being disruptive, if you’re not using the flexibility of your role to learn all the new stuff you can, and then striving to show people a better way of doing things, you’re not living up to your potential as a Tech Artist.