Transitioning from Audio Design, to Audio Programming

It's a difficult challenge.

I changed from a film audio post person, to an Audio Design in games position, to a Tech Audio Designer, then into an Audio Programmer. It's been great for my career, but there are some interesting lessons that occured along the way, that I thought it meaningful to share.

1. Great audio design informs great technical solutions.

Without good sound design chops, an ear for physics or the neurological understanding of sound as a psychological tool for influencing players or story (or just plain listeners), you're sort of stuck. While the initial challenge of game audio is "Why the fuck doesn't this sound play", it soon morphs into a trivial matter, and leans back on HOW we make the player feel when playing sounds. As such, my experience in post audio, and then in creating assets as a sound designer, and then finally as a transition into games was one of understanding great audio design, and the sort of layers and principles I'd normally use in linear media, as a dynamic element.
2. Technical skill changes everywhere, implementation does not.

I've worked at quite a few places now, with tasks like hand-building entire audio systems, to simply maintaining or supporting the structure of larger engine architectures, and the main thing I've seen is that the implementation of a specific set of sound behaviors seems to be the same (ish), but HOW they are done can differ widely. This leads to incorporating a number of languages and design structures, and tight communication with the game engineering team to ensure you understand both the principles and practices of good software architecture, so you get OUT OF THE WAY of the game programming team, while still achieving some of the lofty goals your audio design team might have. Learning languages can be a massive challenge, and you never know what you'll need (for one project, a UI sound meant React, Python, Javascript, C# AND C++ just to implement the damn thing!) so absorbing and building smaller prototypes and improving your code *comprehension*, as opposed to hardcore programming chops feels (to me) more important when developing into a technically minded person.

3. Outstanding Achievements should be celebrated everywhere

There's a propensity for audio designers to get credit when they make great sound, and throwing assertions and bugfixing being relegated to more technical roles. Instead, you should realize that the team works TOGETHER, with Technical Audio Designers informing audio designers of their own work, as much as sitting with them and discussing why things should be implemented to facilitate a system in a specific way. When performance matters, audio programmers can help technical audio designers, protecting them from creating costly systems or facilitating said systems by borrowing performance from elsewhere in the project. When you do this as a team, it really gets cooking, and you begin to see the wonderful side of getting a group of audio professionals in the room

4. The separation is real, audio programmers are still audio people

In my case, I took on programming because of a lack of skill in the team, and a lack of understanding of audio programming, or how it could unblock the audio team. We built a strong foundation of coding skill, and, while we celebrated and high fived as a team, I felt further and further removed from "the audio team". This can be added to by not being invited to meetings, or being considered "just a coder" without considering that an audio programmer is usually still an incredibly devoted audio PERSON. As such, including audio programmers and technical audio designers in regular conversation about the music you're listening to, and the game audio you love, and getting them into game groups can be challenging, because they work in such a different part of the engine than you do, but they are a rare superpower to have on your team. It is NOT uncommon to not even HAVE an audio programmer, relegating audio programming tasks to an engine or gameplay programmer instead, much to the deficit of technical audio designers

5. Collaboration and team oriented behaviours become more important, the more technical you become

An audio designer can happily smash out assets and, if they learn to implement them (which you should definitely do anyway!) can go about their business, popping sounds into the project willy-nilly. Unfortunately, unchecked, this can be rife with danger, leading to lots of the "Nobody thinks of sound" rhetoric that exists in studios and small teams. Technical audio designers should absolutely become friends with technical artists (it's BASICALLY the same discipline, but a different medium), gameplay designers, producers and more, with a foot in the programming pool for great new debug options that can speed up their workflow. It sounds like a silly principle because collaboration you would think is obvious, but professionally it's important to broaden your understanding of wider game design principles, the further you go.

Oh, and become the source control expert on your team regardless of position, because you'll be utterly indispensible with this on your tool belt.

Anyway, I got a little carried away waxing lyrical about this, so hopefully it answers some of your question about taking your audio skills to a WHOLE OTHER LEVEL by integrating some programming skills into your repertoire.