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?

yeah these are quite effective techniques, hardly employed fully:)
I cant share more opinions because i have never been into professional prgramming however i have 2 years of experience. What you have shared is good. If i find more i will!

http://www.outsourcing-partners.com/php-programmer.html Joe

Good catch abt game programming..

http://www.definitelyambiguous.com/ Joseph Barbour

As a former software tester that worked closely with the programmers, I can say that cross discipline work will save everyone a bit of time. Testers are able to point out possible problems even from the planning stages, programmers can develop tools to make everyone’s jobs easier, a technical artist can bridge the gap between the two thinking hemispheres, and a good manager can keep things flowing smoothly.

Also, I’m a big advocate of constructive criticism. Sometimes you have to pry it out of someone, but their insight can lead you to a discovery that improves your work considerably.

JD

As a young developer who isn’t good with thinking outside the box I found myself repeating code and copying lots of code to do things that a loop or more complex code can do with a lot less code