It's not about technology for its own sake. It's about being able to implement your ideas.
There's a strange dichotomy that college doesn't prepare computer science majors for: knowing how to program is a huge benefit if you want to create something new and useful, but as a programmer you're often viewed as the implementer of someone else's vision--as just the programmer--and have limited say in crafting the application as a whole.
(Note that here I'm using "application as a whole" to mean the feature set and experience of using the app, not the underlying architecture.)
In my first game development job writing 16-bit console games, I naively expected there to be a blend of coding and design, like there was when I was writing my own games for home computer magazines, but the two were in different departments in different locations in the rented office park space. It had never occurred to me that a game could be failing because of poor design, yet I wouldn't be able to do anything about it, not having a title with "design" in it. I came out of that experience realizing that I needed to be more than an implementer.
I wanted to write up some tips for people in similar situations, people who want to be more than just the programmer.
Go through some formalities to prove that you have domain knowledge. You might think you know how to design good user interfaces, but why should anyone listen to you? Buy and read the top books in the field, have them at your desk, and use them to cite guidelines. Or take a class, which might be less efficient than reading on your own, but it's concrete and carries more weight than vague, self-directed learning.
Don't get into technical details when it doesn't matter. "Why is that going to take three weeks to finish?" "Well, there's a new version of the library that doesn't fully work with the C++11 codebase that we're using so I'm going to have to refactor a few classes, and also there are issues with move semantics in the new compiler, so..." No matter how you say this, it sounds like complaining, and you get a reputation as the programmer who spouts technical mumbo jumbo. Sure, talk tech with the right people, but phrase things in terms of the project--not the code--otherwise.
Don't get into programming or technology arguments, ever. Just don't. Again, this is usually thinking on the wrong level, and you don't want to advertise that. There's also this Tony Hoare quote that I love:
You know, you shouldn't trust us intelligent programmers. We can think up such good arguments for convincing ourselves and each other of the utterly absurd.
Get to know people in departments whose work interests you. Continuing the user interface example from above, go talk to the UX folks. Learn what they like and don't like and why they've made certain decisions. They'll be glad that someone is taking an interest, and you'll be learning from people doing the work professionally.
Build prototypes to demonstrate ideas. If you jump in and do work that someone else is supposed to do, like changing the game design, then that's not going to turn out well. A better approach is to build a small prototype of a way you think something should work and get feedback. Take the feedback to heart and make changes based on it (also good, because you're showing people you value their opinions). Sometimes these prototypes will fall flat, but other times you'll have a stream of people stopping by your desk to see what they've heard about.
permalink October 16, 2016
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?