Broadcast Engineering is one of those fields that requires a wide range of skills. Traditionally, you’ve needed to be a RF engineer, electronics engineer, IT guy, electrician, general handyman, acoustics consultant, and much, much more. However, I believe that one of the most important skills for a broadcast engineer today is one that most don’t possess – software development skills.


You can’t pop open a broadcast console these days and expect to do much. Even if you can replace a fader, button or power supply, you can’t expect to actually substantially change the functionality of the desk. The same goes for automation systems, processors, hybrids, phone systems, websites, and all manner of back-office systems. It’s all software-based.

Unfortunately, you generally can’t modify these products in code either because they are closed source. What you can do is interface with them using open protocols to extend functionality and innovate.

Lately I’ve been seeing some cool little open source broadcast projects pop up. These include the Raspberry Pi Studio Clock and a Axia Livewire EBU R128 loudness meter.

These aren’t fully-blown applications. They don’t represent substantial development efforts. They are small projects well within the grasp of the casual programmer with a desire to solve a problem.

I’ve got a few of my own, including OnAirHope (an on-air metadata system), HOPECaster (podcasting helper) and TallyMate (on-air fundraising assistance software). Then there are a few migration scripts I’ve written recently to migrate from Dalet 5.1 to RCS Zetta, and Umbraco to WordPress.

While some of these tools are bigger than others, the basic point of them all is to solve an immediate, real-world problem. This is about a broadcast engineer identifying a problem and solving it, just like engineers have done for generations. The difference here is that it’s with code rather than diodes, capacitors, transistors and isolation transformers.

These sorts of things excite me. Real problems. Real solutions. Simple software solutions.

Broadcast engineers have traditionally been drivers of innovation. One example is Steve Church, who created DSP-based hybrids and transformed talkshow broadcasts. Learning to code allows you to drive innovation within your organisation. You might not create the next Telos Systems, but you can still make cool stuff and deliver value.

Learning to write code will also help you talk to other developers and gain a sense of how hard something is to do. When you are dealing with vendors and making a change request, or writing a specification, or talking to web developers – having at least basic programming skills will help you communicate.

The other thing is that you don’t always need to be writing code in order to benefit from the skills. Programming gives you a more solid understanding of how software works, which informs and helps your troubleshooting process. You learn about things such as character encoding, input/output sanitisation, databases, and communication protocols. Just learning about databases can help you improve the performance of your playout system through indexing.

The question now becomes… how do I learn to program?

These days, there are plenty of websites you can learn from. Sites such as Code Academy make it easy to get started. After gaining a little bit of knowledge, start identifying real-world problems you want to solve and tackling them head-on. This will keep it interesting.

There are plenty of languages you can learn. I personally started with PHP, but have more recently got a lot out of Python. It’s particularly good for broadcast engineers because it’s got a fairly low learning curve, allows multi-threading, socket connections, database connections and much more.

The point is that learning to code is a valuable skill to have, and something that I personally have got a lot out of. I’ve been able to provide real value to the organisations I’ve worked for. I’ve saved money and delivered innovation. I encourage you to do the same.