4 Ways Performing Is Like Programming

The Set-Up

When I started getting ready to perform music as a solo artist, I learned a number of humbling things about my capabilities.

• I couldn’t play any song through completely without mistakes
• I was not physically able to play certain things, leading to covering behavior or just blundering through and sounding awful
• I almost never played a song through from start to finish
• I couldn’t recover from mistakes and “catch up” to the music

It took a long time and a lot of work to get to the point of feeling comfortable about those things. I’m still not perfect at any of them, but a lot of practice and some experience performing have made a big difference.

This led me to think about programming. It’s an imperfect metaphor, because I’m talking about playing or performing as opposed to composing, which would seem to be the equivalent. Can you imagine coding as performance art ? Where it’s not the result that counts, but the method of getting there— the cadence of typing, or the posture and motion of the programmer, or the use of formatting and color in the source code.

But while that’s a pretty fantastical visual, I wondered if I could make more of it. What would I find if I took the metaphor a little more seriously?

Thought Exercise

Are there parallels between music and programming that change our perspective? Can we learn something about programming from performing? Or vice-versa? With that as a setup, I’ve rewritten the four learnings I listed above to change the context to programming.

I make mistakes, often stupid mistakes, when I am writing code

With an instrument, there is no escaping the need to practice. Often, we warm up prior to playing by doing physical exercises, scales, and études. How many times have you stretched your neck, shoulders, hands, and wrists before writing code? Do you warm up by doing some other technical tasks before diving in or by solving some LeetCode problems? Would that make you more effective? I don’t do those things, but I do wonder if they would help.

In music, making a mistake is problematic because it works against the musical atmosphere and narrative you are trying to express. And you don’t really get second chance when you are performing live. In programming, the impact is different, but there are parallels. Promoting a bug that affects people who use your service is not unlike making a mistake during a performance. And there’s a good reason to not make mistakes, as it has been shown that defects cost more the longer it takes to discover them. This makes me wonder if I should adopt a warm-up process before I start on the technical work.

I am not strong in certain aspects of the language

The knowledge of music theory is central to defining the capabilities of most musicians, as is computer science theory for programmers. In the same way you might debate the pros and cons of different sorting techniques or types of programming languages, musicians can choose between many different ways to play the same piece of music on many variations of the same instrument. And programmers have plenty of practice forums available, like the aforementioned LeetCode, HackerRank, and others.

But I am struck by the similarities in how we learn. To learn something new in music, we have to learn the theory first and then practice and understand it. It’s not uncommon after that to learn a song that expresses that concept and experience it in practice. The final step is to take that concept and improvise with it. In programming, it feels similar. You learn the theory, then use practice exercises to implement it, and then you are ready to improvise by adapting this concept to the problem you are trying to solve.

Having said this, and because there is a performative element to it, I think the percentage of time spent practicing versus performing is much higher in the music world than in the programming world.

I take shortcuts to speed things up

We occasionally face choices and trade-offs. If I am playing guitar, for example, I will typically be using a practice amplifier, not playing a Marshall stack at high gain. The practice amp has modeling, so it can pretend to sound like anything. It frees one from the need for a big amplifier, loud volumes, chains of pedals, and other complexities. To me, this is similar to developing and debugging locally and then bringing that code up to the dev, test, and other environments.

But I think there is a more powerful similarity. In programming, we might choose a less efficient method to do something quickly rather than crafting a more elegant (and time-consuming) solution using a more complex feature of the language. Time-to-market demands that prioritize speed over all other factors also influence these decisions. This is frequently the origin story of how technical debt is created.

When I only practice or play part of the composition, am I creating “musical debt?” By only focusing on a specific section, I am choosing not to practice the rest of the composition, or those sections where I transition in and out of the part I am focused on. When I play the thing live, I might very well nail the section I was practicing and then screw up some other part. Or, alternatively, if I am in a rush to get ready to perform a piece, I start making other tradeoffs. Drop the complicated rhythm, change the chord structure to something simpler, and so forth. This feels like musical debt, because in order to go back and play it as intended, I have to refactor the passages that I hacked by learning the correct rhythm or chords.

I get lost in my own code

When playing, whether solo or as an ensemble, making a mistake can cause you to lose awareness of where you are in the music. You get so focused on a specific passage due to some complexity (challenging time signature, difficult to physically play, etc.) that you are not able to snap back to the composition after you make a mistake. It’s interesting because when you make a mistake, you are now operating outside of the composition. You are playing something that is not in the score. But you can also get lost in your own code.

That article suggests that warming up, working in phases, and commenting effectively are good countermeasures for getting lost in your code. But in music, this mostly goes right back to practice. When you practice a difficult section of music over and over again, there are a few benefits. One is better technical performance of that section. But another is the reduction in cognitive load you experience while playing the section. It takes less brainpower with all that practice, leaving you with more cognitive headroom to maintain awareness. It would seem to follow that if you want to minimize your chances of getting lost in your code, you should focus on getting better or more efficient at the things that drive cognitive workload while you are programming.

The other interesting thing about getting lost in a composition is the similarity to outages. Let us define an outage as putting a complex software system into an unknown state. How do you return to nominal behavior? If it’s an unknown state, you probably don’t have a runbook for it. With music, there isn’t really a standard way to snap back to the composition. There are typically only a couple of options to choose from, and neither is very good.

1. Speed up to catch up. You play from where you were, but play faster to catch up to the composition. To me, this is similar to scaling up a resource to get out of an outage. It works a lot better in IT than in music, where it tends to sound horrible.
2. Jump back in at some future point in the composition. This is similar to a restart or reset in the IT world. The problem in both is the same—there is an absence of the thing while waiting for the reset. That can ruin a musical performance, especially if it’s a solo performer or a small ensemble. Likewise, in the IT world, it means that something is down. That is not good in either context.

But I think the key uniting concept here is that you need excess cognitive capacity to avoid getting lost. If you have a high cognitive workload, you are less likely to have the capacity to maintain awareness.

What I Learned

This is a thought exercise, clearly, but it did provide some interesting perspectives. I take things for granted, like stretching. I often stretch and warm up when playing, but almost never when programming. Likewise, I am more likely to write a snippet of code than to learn a new algorithm, at least outside of my professional work.

However, it does cause me to reconsider a few things: first, that I ought to incorporate some of these practice methods into my technical work; second, that I ought to consider musical debt in the process of evaluating my ability to play something in order to arrive at a more thorough assessment.

This raises the question of whether the value of the typical programmer to the team could be increased by concentrating more on the fundamentals and cognitive load. To illustrate that, consider this final similarity between music and programming. In both cases, some of your greatest contributions are things that make it easier for everyone else around you to excel.

Epilogue

By the way, I later started to get serious about recording. It was then that I learned another set of humbling truths:

• I don’t play in time
• My control of dynamics is much poorer than I thought
• I make a lot of extraneous noise through breathing and movement

So apparently I will have plenty to think and write about on this creative journey.

If you have stories or observations about music versus programming, please do tell in the comments.