From the Mixing Desk to the Machine
I spent four years running live sound for television before I wrote a line of production code. It turned out to be the best engineering education I could have had.
Most engineers I know started with a computer. I started with a mixing desk.
From 2011 to 2014 I ran sound at Art Center Pro, working on live television — the kind of productions where a talent show goes out to an audience in real time and nobody watching cares why the audio dropped. There is no staging environment in live broadcast. There is no rollback. The show starts, and whatever you built has to hold for the next two hours.
I think about that more than almost anything else I learned later.
Live production is systems engineering with the safety net removed
When you run sound for a live show, you are not really operating equipment. You are operating a system you assembled in advance, under time pressure, knowing that some part of it will behave unexpectedly. So you build for the failure you can't predict:
- Redundancy is not optional. You have a backup path for anything that would end the show. Not because you expect the primary to fail, but because the cost of it failing is unrecoverable.
- You monitor what matters, continuously. Not after the fact. During. You need to know something is drifting before it becomes audible to a million people.
- Recovery beats prevention. You cannot prevent every fault in a live rig. You can make every fault recoverable in under ten seconds.
Swap out the nouns and that's a production engineering checklist. I just learned it with a pair of headphones on instead of a terminal open.
The transfer was not obvious at the time
When I moved into software testing in 2016 — freelance work with Applause, then Ubertesters, then Smule — I assumed I was starting from zero. Everyone around me had a CS background. I had a live sound background and a lot of opinions about signal flow.
What I found was that testing rewarded exactly the instinct live production had built: the assumption that things break, and the discipline to go find out how before someone else does. Good testers aren't pessimists. They're people who have internalised that the show goes out either way, so you had better know what's in the signal path.
I was, it turned out, unusually comfortable with the idea that the system would fail. Most people find that uncomfortable. I'd spent four years with it as the baseline condition.
Where it leads
The thing about believing systems fail is that it eventually makes you want to build systems that handle their own failures. That's the thread that runs from a mixing desk in 2011 to what I do now: building codmir, a platform where autonomous agents do the work and the interesting engineering problem is what happens when one of them is wrong.
Same problem. Much larger rig.
If you're coming into software from something that isn't software — audio, lighting, logistics, anything operational — you are probably not as far behind as you think. The instinct that the system will misbehave is most of the job. The syntax is the easy part.