Lately I’ve been tinkering with game development. It’s an aspect of software development that isn’t part of my job and I’ve always had a hankering to produce a game of my own one day. In addition to having to learn practices and concepts I’d never come across in web or backend development, I’m learning a new programming language as well. I settled on learning Godot, a game engine more than capable of producing a 2D game that I’d want to make eventually. Godot has excellent C# support, but I am taking the opportunity to pick up its native Python-like language, GDScript, instead.
I have progressed somewhat in my journey of game programming but have only scratched the surface. As I was picking up GDScript, I thought about the processes in general that I, or anyone, go through when it comes to learning a new programming language, whether it be for work or for a new hobby. It can be intimidating, but I’m here to assure you that if you’re already a software developer in any capacity, it’s not so bad!
Think Like a Musician
When a musician wants to learn how to play a different musical instrument, they are not starting from scratch. They already have music theory learned, how to read music (or other methods of playing), etc. Shifting from the piano to the guitar involves learning new muscle memory and techniques, but the foundations of their training are still present and apply to playing music. There is always new stuff for them to learn and practice, but compared to someone who’s never touched an instrument before they are already leaps and bounds ahead.
Picking up a new programming language is a lot like this. The bulk of principles and best practices learned are aspects of development that don’t have to be picked up again. There will be different ways of going about said practices. For example, GDScript doesn’t have strong typing compared to C#. However, the understanding of the importance and reliability of those practices is intact. As I learned the fundamentals of how one works in a Godot / GDScript ecosystem, it was all about learning how to do basics (conditions, loops, syntax, etc.), not starting from scratch. I learned the new fingerings and muscle memory required to write out GDScript and was good to get started. Naturally, my C# is leagues ahead of my nascent GDScript endeavors, but I can still rely on all my work within C# despite not using it here.
Choosing Your Rosetta Stone
Quoting Wikipedia:
The Rosetta Stone is a stele of granodiorite inscribed with three versions of a decree issued in Memphis, Egypt, in 196 BC during the Ptolemaic dynasty on behalf of King Ptolemy V Epiphanes. The top and middle texts are in Ancient Egyptian using hieroglyphic and Demotic scripts, respectively, while the bottom is in Ancient Greek. The decree has only minor differences between the three versions, making the Rosetta Stone key to deciphering the Egyptian scripts.
When picking up a new programming language, you already have one under your belt. From that you can build out a personal Rosetta Stone (or better, find one that exists already) that can ease you into a new language. For me, obviously, my root language is C#. A common documentation or web search I performed when learning GDSCript (and other languages in my day-to-day work) is finding equivalences between an operation in a new language, and C#‘s LINQ feature set. A set of operations one does across all languages is that of filtering, projection (i.e. LINQ Select), sorting, and so on. “LINQ Where Equivalent GDSCript” is an example of a search I most likely performed, leading me to learn that GDScript arrays have many LINQ-like functions built in. For those curious, GDScript arrays have filter() as its Where() equivalent. This is a perfect example of me referencing my “Rosetta Stone” (C#) to easily translate from what I’m used to the new language.
Solve Simple Problems to Learn
The last thing you want to get bogged down with when learning a new programming language is the tangled web of a complex problem to solve. When kicking off learning GDScript I didn’t set out to make a massive video game with tons of features and intricate systems. I made Tic-Tac-Toe!
This game is incredibly simple to understand and play, with a very small set of rules to program in and get working. Removing the mental burden by starting with a trivial problem lets you zero in on learning the new language itself. Going back to the musician analogy, a musician doesn’t warm up or pick up a new instrument by jumping right into a complex musical piece. They use simple scales and other elementary exercises to prepare and learn a new instrument. Having a set of simple exercises at your fingertips can go a long way in learning a new language, and there are plenty of resources online to get you going. Jumping into Project Euler’s set of challenges is a good example. Where else can we go?
The Power of the Code Kata
Completing code katas are a great way to sharpen your programming language skills. This catalog of Katas from Ardalis has a whole lot to choose from and is a perfect way to learn a new language, again tapping into the concept of keeping the problem simple so you can focus on the language particulars itself. In my case I chose a simple game to kick off my Godot/GDScript endeavors, but I could also easily work from many of these Katas as a starting point. It’s a great resource to have when you have nowhere to begin or can’t think of a simple problem that would work well. Katas serve as a great training ground even for a language you’re well-versed in, if you want to explore a new concept in a language you’re already familiar with (such as Test Driven Development). The versatility of the code kata cannot be overstated.
Practice Practice Practice
Any musician will tell you the key to success in playing music is to play music. Sounds obvious, but it can be easy to fall into the trap of trying to learn everything before picking up the instrument and starting. At the end of the day, no matter how much music theory you internalize or techniques you read about, it doesn’t mean anything to the audience you’re sitting in front of if you can’t play the music! The same is true for working in a programming language: If you want to be proficient in writing code, you must write code! Another boon to keeping the problem simple is to encourage you to get moving on the coding instead of fussing over trying to internalize all the mechanics of a language. Coding every day, even for a little bit of time, in a new language will solidify the concepts much more readily in my experience. Sitting down and solving a (simple or otherwise) problem forces you to go from start to finish in a program. In GDScript, it wouldn’t mean much if I knew every method available to me on an array. It’s much more valuable if I wrote a complete, if super simple, game to understand what’s required of me. The language I’m using is the tool to create the game, not a bucket of facts I need to learn cover to cover.
Summary
- Learning a new programming language, while not trivial, does not have to be a daunting task
- Existing knowledge of concepts and practices transfer easily between languages
- Use a language you know as your Rosetta Stone for translating mechanics to the new language
- Solve simple problems using the new programming language through the use of Code Katas or other easy exercises
- Write code!
As with learning anything new, the process of mastering a new programming language will take time. You can learn enough to be dangerous right away but mastering anything can’t be crammed or rushed. Indeed, learning a new programming language itself is a skill, and the more you practice that, the better you’ll be at picking up new languages. Much like the versatile musician who has done the rigamarole of learning several instruments, learning another programming language becomes easier the more you do it!