Over the past 12 months I’ve worked as the sole programmer on the three games we’ve made. I’ve just started up a new project with a fellow programmer and found that I’ve picked up some bad habits in those past 12 months. I’m continually trying to make myself a better game programmer and today I’m sharing my thoughts on this topic.
Constructive Criticism
The most important way I feel I grow as a programmer is to listen to criticism from my peers. In the past (particularly during puberty) I found this quite difficult to do. Over the past few years as my confidence has grown my view of constructive criticism has changed from fear to embracing wholeheartedly. I’m now at the point where I’ll purposely ask people to give me negative feedback on my code, design, games and in general so I can learn. If nothing else in this list resonates with you, I strongly recommend at least thinking on this point. I’ve met many programmers in the past (including myself) that either ignored criticism or actively fought it. There will always be better programmers than yourself out there and taking constructive criticism from these people is an excellent way of improving.
Continually Learning
I tend to go through peaks and troughs when it comes to reading and learning. During the middle 80% of a project and particularly deep within crunch I find I put my blinkers on and ignore most of the world around me. Once completing a project, and as I start on a new one I’ll resurface and look at what I’ve missed in the previous months. I think learning new techniques, technologies and generally discussing game development with my peers is a great way of improving my skill-set and maintaining an optimal development velocity. I generally count GDC in this as I find I’m invigorated after each visit to SF.
Complete Difficult Problems
When time is short (when is it not) for a particular milestone I find myself shying away from difficult problems in favor of a quick fix or doing something different entirely. I’ve found this is often a sub-optimal solution as the problem is often not solved and inevitably crops up again later in the project. On a project-wide time frame the problem ends up taking far more time to solve than if I had simply taken the time initially to solve the original difficult problem at the expense of the milestone time frame. My solution to this situation is to allow enough padding in my milestone estimates so that I have time to dig deep into a complex problem when needed without worrying too much about the ticking clock. This is easier said than done, however focusing on the project-wide velocity improvement makes it an easy choice to solve complex problems as they crop up.
Cross Discipline
Unlike other software development I’ve done, game development has an extremely wide range of skills across a team. One of the most stark differences is between programmers and artists. With our different hemispheres at work programmers often band together and feel like they are working against the other disciplines in the company. This was the case for the first few jobs I had in the video game industry and it wasn’t until I worked on a cross-discipline team that I realized how incomplete my earlier teams had been. Without a working knowledge of the other key areas of game development I was missing a large part of the big picture. Not until I sat next to an artist and watched them complete repetitive tasks for hours at a time did I realize that spending 10 minutes writing a simple tool for them would make their live much easier. It wasn’t until our latest game that I worked closely with a sound engineer and learned how easy it is to build an extremely powerful sound system to rival many AAA games on the market. Spending time with developers from other disciplines is invaluable to both becoming a better programmer and improving the quality of your team.
Critical Thinking
I often fall into the trap of completing a particular task in a certain way as “that’s the way it’s always been done”. It’s not until I discuss my processes and thinking with other programmers that I realize there can be a better way. There are two main groups I find I get the most “aha” moments that often have radical changes to the way I do things. The first group is junior developers newly out of university. They will often be exposed to new ways of thinking or have simply thought outside the box to solve problems. The second group is developers from outside the video game industry. Test driven development is a great example of something I picked up from a web developer friend (and have since started evangelizing to other game programmers). Looking introspectively at your processes and development style at the end of a project is a great time to be critical of how you do things and see if you can improve.
Conclusion
Do you have other recommendations and thoughts on becoming a better game programmer? What techniques have you picked up over the years that have helped you grow?