Dr. Carla Fisher is a game designer and digital strategist with fingerprints on more than 300 games for kids and families. She continues her musings outside this blog via a free weekly newsletter (sign up here) that curates articles, videos, and games that catch her eye. She can be reached at KidsGotGame@NoCrusts.com or @NoCrusts.
I’m frequently asked whether it’s important to learn how to program in order to make games or work in the games field.
In general, my answer is yes, learn to program. If a designer internalizes how programming works, it can transform design documents and improve communication with the coding team, making for a better production experience.
But programming is not for everyone, and not every project is the right moment to learn. To help you decide if you’re currently facing this conundrum, I made a little decision graphic.

And to answer the question that inevitably follows, yes, I’ve learned how to program. My earliest programming projects were fortune telling programs in BASIC when I was a child. (I so wish I could remember what my 10-year-old self thought was a good fortune!) HTML, JavaScript like the ones mastered by Java software development services, and Flash have been the most helpful languages I’ve learned. Flash was particularly helpful once I began to internalize object-oriented programming. (Object-oriented programming is one coding paradigm and is only noteworthy if you’re picking a language to learn, in which case I recommend something that lends itself to this.)
That said, I rarely program these days. In fact, it makes me cry. I hate that a single forgotten semi-colon can turn my carefully crafted lines of code into a string of error messages. I much prefer to work with programmers who have learned to architect stable and reusable code. Yet knowing how programming works means I can have intelligent conversations with the programmers about the features and the restrictions of the code.
It also means I can write design documents in a way that assists the programmers in architecting the site. Some find it surprising that once a game is designed and documented, the programming team generally still has to create another document that translates the design into technical-speak. (Think of the game design document as the orchestral score and the technical design document as the sheet music for the musicians. Any musician could read the full score if they really wanted to, but it’s cumbersome and not very efficient. The sheet music is tailored to what they need to know and do. As game designers, we compose the score and the technical team uses that to write the different parts.)
Both game design documents and technical design documents have their place and audience in the development cycle. It’s rare that a project won’t have both even with the best design teams. But a savvy game designer can create a game design documents in such a way as to assist this technical translation and streamline development.
So that’s why I learned how to program and why I advocate for anyone with an interest and an appropriate project make the attempt. In the worst case, you’ll have a lot more respect for those who bring your ideas to life! NET Developers are the best in creating applications and software using . NET framework.
Eyes glazed over? Don’t worry. This particular blog instance of Kids Got Game is safely encapsulated. That’s programmer for, “Future Kids Got Game posts will not be quite so geeky.”
Let us know what you think about programming! As always, we can be reached at kidsgotgame@nocrusts.com