Music and Software Have More in Common Than You Think
Hint: neither one requires superpowers.
To my surprise, the reactions I received were more akin to amazement. Disbelief that it could be humanly possible to do such a thing. Admiration at the innate, intangible abilities involved.
Now, where have I experienced that sort of reaction before…
…that’s right. Talking to non-musicians (or “normal, healthy, functional human beings”, as we musos tend to call them) about cello playing. It appears that if you want to be perceived as some sort of superhuman, you just need to pick the right crowd.
The irony, however, is that these two worlds are not vastly different. Had they been, I imagine that I might have found a completely different way to diversify. Or, given up on the idea and just practiced loads… But anyway, here’s a list of similarities I’ve found so far — I imagine I’ll end up adding a bunch more, probably at some ungodly hour when my brain decides that random thoughts are better than sleep:
- Both fields necessitate fluency in some abstract, esoteric language that combines text and symbols. There’s sadly less googling in music, but that’s probably because music notation wipes the floor with any programming language in terms of age, longevity and universality.
- Getting a job in either field usually involves actually demonstrating your abilities, rather than merely talking about them. With that said, I would kill for an audition situation where, if I can’t play the piece well, I can at least whiteboard it and explain my logic.
- In both cases, the products being created are intangible, non-corporeal, and limitless in possibility. These products are also invariably created on hardware that is expensive, fragile, and calibrated with often neurotic degrees of specificity.
- Additionally, being able to get a job, and thus the means to afford said hardware, is often contingent on having the expensive hardware in the first place.
- Simultaneous focus on both the big picture and the finer details features prominently in the development stages of both — and indeed, an awareness of the hazards of only paying attention to one of those two things.
- Problem solving is a major part of music-making, and creativity is a major part of coding. (In your face, lazy stereotypes!)
- “Failed to compile” == “Thought I could wing this bit in the concert without practicing it properly”
- Both are subject to rigorous testing in the development stage, and in the most thorough examples will factor in all sorts of edge cases to ensure that the product is as watertight as possible.
- Collaboration is an inevitable part of both, and communication matters. A lot.
- “Practice” comes up regularly in conversation; in the case of software engineering, this will be prefixed with the word “best”. Think “cellist me” might have missed a trick there…
- Pattern recognition. Learning new coding languages is made considerably easier by spotting similarities with ones you already know — no matter how you dress up a ‘for’ loop, it’s still a ‘for’ loop! Similarly, learning new pieces is made considerably easier by spotting bits of the scales and arpeggios that you’ve practiced religiously for years. If any of my students are reading, that was *absolutely* a hint.
- Both are scalable. (Sorry, couldn’t resist)
In a nutshell, a move into software from music might seem like a daunting prospect, but I’d be willing to bet that the majority of people in the rehearsal studio that day could do it.
As for the conductor, there’s always product management.