Yesterday I gave you the opportunity to pre-order my new guide on ChucK programming – Like Magic – and I left you with this question:
If you’re going into programming or technical sound design, how exactly will this guide help you?
So, let’s answer that.
Skills that get you Hired
A bunch of you really want me to open up more spots in C# Implementation with Wwise and Unity.
Why is that?
Most of you want more spots to open up so that you can gain technical skills and abilities you can use on a demo reel or in your resume. In turn, you hope this will be the thing that gets employers to hire you.
In short – you’re not actually buying the product for the skill itself, you’re buying it for a job.
But that one thing alone will not get you hired. It won’t – I promise. There’s no single magic bullet to job acquisition.
You can’t buy a job.
But – you can build one.
Here’s the “shortcut” to what employers are looking for, and what I’m always selling you. Quite literally, in every email and product.
Employers want a person who understands their unique problem, can verbalize said problem to demonstrate understanding, and exhibits skills and traits that indicate a competency to solve said problem with flying colors.
So how does that at all apply to a book on ChucK programming?
Well, let me tell you with a story.
Why I Get Hired
Factually speaking – I’m good at navigating the process I described above. I’ve spent my whole working life understanding and perfecting that, and will continue to do so. It gets me work.
Consequently, I understand why people hire me in games (and, most everywhere else I’ve worked).
If I get hired – and I’ve bombed some pretty big interviews – it’s because of this formula:
- I asked for clarity about, and clearly understood my potential employer’s problem
- I told them so in a way they understood
- I demonstrated that with my work – often, we barely even talk about this part
Such has been the case when I’ve gotten jobs with AAA game studios.
Most of my clients, generalized, have these problems –
- They’re making a game on a limited time schedule
- They don’t have time to teach someone how to make a game or work with the tools on the job
- They need someone who can learn their unique systems (or build them) on the fly
- The team doesn’t speak “software developer” well, if at all
- The team requires software developers to build and support features
- Software developers tend to ignore the audio team or brush them aside
- The team may need some extra programming done that software developers don’t have time to handle, because of point 6
- Did I mention we have a game to build that has to both sound good and make money?
Usually, you all can deal with problems 1-3 just fine. You also assume that will get you a job.
With Technical Sound Design, that’s often not enough.
Because of that, you jump straight to problem 7 – you assume that the developer needs a bunch of programming. So you learn C#, Python, Lua, etc.
None of those things are bad – but the divide between content and engineering is great enough that this is often a delicate line in AAA. You can’t just assume you’ll be programming and that’s what the team wants and needs.
I get my work because I most often deal with problems 4-6.
- I understand audio content creation, and its needs and issues
- I understand how to speak with and work with software developers
- I can bridge the gap, live, in real time
And I can do programming and sound design where needed. Am I the best at either of those things? Not even close. At this moment, I couldn’t get a “real” audio software developer job if I tried (give me a few months). But I don’t need to be for my position. You don’t need to be either.
You do need skill acquisition – just not the skill acquisition that you think you need.
Like Magic
I understand audio well. I’ve been working with audio since 2004 – so 15 years. I know how to handle audio in a bunch of different contexts.
At one point, I didn’t know programming and digital audio systems well. I knew enough to get by.
Really, I knew enough to build a website. Everyone knows enough to build a website.
So for the last 3 years, I’ve been working on developing a proficiency and understanding of how digital audio is handled in software.
We all know 48k means 48,000 samples per second. You get that means 48,0000 “pictures” of your audio in a computer in one second.
But what does that mean in code? How is that stored in memory? When you bus two audio tracks together – what is “mixing” actually doing in code? How does all of this processing actually work? And time is important, right? So how do you handle the importance of real time audio while not crashing or locking up every other program on a computer?
These things are second nature to engineers. They’re a foreign language to audio professionals.
Seriously, go hang out with a composer and say “You know, the Calculus involved in DSP is really awesome, right?! OH also ring buffers are a super brilliant idea, don’t you think?”
You’ll be the life of the party.
And I mean it honestly – if you grab a copy of Like Magic.
Because you’re going to go from rolling your eyes at what I said above, to being able to understand more of what the computer is actually doing.
Here’s what’s funny – musicians, sound designers, audio directors all actually care about this stuff. They just care about it in the context of what the audio sounds like and emotes. They don’t care about randomization systems unless you explain how those systems make their games sound and feel better (which middleware has done a great job of).
And Like Magic will take you on the very first step of the journey towards understanding what’s going on in the machine and how it applies to your creative, artistic life.
When you “get it” – and suddenly know more about what everyone is doing around you – doors will swing open. This guide is an excellent first step to that journey.
If that’s appealing to you – the guide is available for preorder today and tomorrow. Then sales will close until it comes out at the end of this month.
https://adamtcroft.com/like-magic
See you one last time tomorrow.
Copyright 2016-2021, NIR LLC, all rights reserved.