What has being an opera singer taught me about programming?
However, the further into tech I delve, the more I realise that the skills I built by studying music and performing on stage are more than applicable to the tech industry, and to coding specifically. Sure, I won’t be singing any arias while creating React components, but there is plenty of crossover worth mentioning.
Knowing the basics inside and out
I’ve entered my one-year web development course already knowing about half the curriculum. I’ve reflected a lot on why I’ve chosen to go this route, rather than smashing out a 3-month bootcamp that will whisk me through and let me learn everything at a cracking pace. I’m a fast learner, why not?
Why, instead, do I choose to put myself through months of slow work covering ground I already know?
Learning the ins and outs of a language can be exciting, and implementing those into projects is one of the most satisfying parts of being a developer, just as shownight on stage with thousands of audience members and thunderous applause was the most exciting part of being an opera singer.
However, this success and this joy has to be based on a solid understanding of the basics, and an ability to keep your skills sharp.
As with scales and intervals in music, I regularly enjoy going over array methods, object methods, CSS selectors, and more. Twitter is also invaluable for providing lots of code snippets where you attempt to guess the outcomes. Do I get them right every time? Of course not! But that brings me to my second point…
Seeking out errors and embracing problem-solving
Opera is often called “the Olympic sport of singing”, and like any Olympic sport, you are expected to work tirelessly to perfect your art. Opera singers spend a lot of money paying people to tell them exactly how they’re messing up: they pay singing teachers to tell them the myriad of ways in which they’re singing ‘ahh’ incorrectly; they pay vocal coaches to show them all the rhythms they’ve mislearned; and they have directors and conductors to show them exactly how the final product should look and sound.
Every part of the industry is geared towards finding your weak points and then working to improve them.
Meanwhile, as a developer, bug-free code is a rarity, and if you go in expecting perfection you will always be disappointed. This can be hard for your average person to understand and accept.
The average person views errors as blunders, and therefore faulty code is understood as an indication of personal failure. What does this mean in the workplace? Defensive colleagues, closed minds, and an inability to admit when you’re struggling. All of which add unnecessary time and frustration to a project.
I have found a strong affinity with the professional developers I’ve worked with because they too tend to enjoy a more blunt approach: “The problem is in line 15” in engineering circles, could as easily be “The problem is in bar 15” in musical circles.
I’ve often had conversations with other programmers about what they find most satisfying when coding, and a majority tend to say “When the project is finished”. For me, I’ve found I’m most satisfied when I find a bug and fix it, and then work out what needs to be done next. For me, the project is never finished, because there’s always something that can be done better, or some tiny error nobody else noticed. This is not a downside of coding to me, and I have the opera industry to thank for that willingness to dive into detail, regardless of whether it means I ‘failed’ or not. Finding points of failure is crucial to delivering an excellent final product, both on stage and in software development.
Communication, teamwork, and trust
Have you ever tried working on stage in a group of 40+ people, all needing to fulfill exact roles, move props, dance, and interact with each other in highly choreographed movements, all while singing to a world-class standard in coordination with a conductor who is also leading a 70+ piece orchestra in front of a crowd of hundreds if not thousands? I have. It’s about as complex and difficult as it sounds, and none of it works if you’re not being totally open and if you don’t totally trust each other.
I hear a lot of talk in recruiting circles about ‘soft skills’, and honestly I hate the term. I’m not alone in thinking it seriously needs a new name. These are hard skills to build if we’re being genuine in their execution.
An amazing programmer is not worth much if they can’t present their ideas, work in a team, follow instructions, and do a task like pair programming without infuriating their partner.
Being an opera singer has taught me not only how to sing, but also how to express complex ideas clearly in a multicultural environment where one wrong move can bring the whole production crashing down. In addition to that, I know that I now have a huge advantage in having zero fear of public speaking and being in front of an audience. This means that, should my career develop beyond programming and into project or product management, I will be one of those who needs no extra encouragement or training to stand up and explain a project to a client or to stakeholders.
Although I won’t be singing while coding, and I wasn’t programming while on stage, a lot of the same skills and mentality that led to a successful career in opera are what I believe will carry me into a successful career in engineering. Not only am I now equipped with the mental fortitude required to admit to problems and to embrace errors, but I am also equipped with the real skills involved in public presentation, working as a team, and embracing the day-to-day practice of basics which build a foundation for expertise and excellence.