Recently, I was writing an article about practice problems in Python when I started to go off on a tangent about music. The idea was that a lot of the skills I learned in music could be translated to programming. Then, I realized that there are probably a ton of skills I’ve picked up over the years that translate well into programming. As a result, consider this the first post in a series about my love of learning new things.
As some of you might know, I’ve been playing trombone for quite a number of years—though it wasn’t my first instrument. I picked it up back in late 2005 when I had just entered 6th grade. I think that puts me now at almost 16 years of experience.
These days, I’m not as serious about music as I used to be. That said, prior to the pandemic, I had been attending a weekly ensemble in Columbus. Before that, I played in middle school, high school, and college. For instance, here’s an embarrassing clip of me playing a mediocre solo in high school:
In all that time, I feel like I’ve learned a thing or two about how to get better at music—though I’m no expert. As a result, I figured I’d share some of the practice skills I’ve learned through music and how they could map to a skill like programming.
I won’t get too deep into philosophy, but I feel like our society prioritizes specialization too much. I try to reflect this belief as much as possible in my daily life by engaging in new topics and activities regularly. For instance, I recently picked up chess, and I’ve started playing RPGs for the first time in awhile. Naturally, one of those skills I’ve picked up is music.
Music is interesting because it’s surprisingly similar to programming. In fact, I’ve made this argument before while talking about programming language classification. If programming is getting a computer to behave a certain way through a shared language, is music not similar? Instead of using Python, musicians use common music notation.
As a result, I see music to be similar to programming in a lot of ways. For instance, contrary to popular belief, I think programming is a creative endeavor. There are a lot of choices you get to make which are decided through your own style. Not to mention that creating stuff is inherently a creative process.
All that aside, I thought today we could talk about ways to get better at programming using some of the practice techniques I’ve seen in music. Specifically, there are three skills I can think of that map quite nicely to programming: transcription, transposition, and sight reading. Certainly, there are musicians in the crowd that can back me up on this!
One of the skills I’ve learned from music is transcription. If you’re not familiar with what that means in the context of music, it’s basically the process of converting audio into sheet music. Typically, this is done by ear with helpful tools nearby like a piano.
Transcription is a useful practice technique for a variety of reasons. First, it forces you to listen carefully to not just rhythm and harmony but also dynamics and tempo. Of course, these are just the mechanics by which music is written. Throughout the transcription process, you can also pickup on patterns and style. These can provide inspiration if you ever decide to write your own music or develop your own style.
At this point, however, you’re probably wondering how transcription is at all related to programming. Certainly, you can’t “hear” a program and turn it into code, right? Of course not! That said, you can observe the behavior of a program and try to replicate it. This is known as reverse engineering.
As far as I know, reverse engineering is very common way to learn web development. Want to know how to make a social media site? Try replicating Facebook or Twitter. Unfortunately, this can be a bit more challenging in more obscure fields like data science and machine learning. Of course, if you’re relatively new to programming, you might try to replicate common built-in functions in your favorite language. I do this in my “Roll Your Own Python” series, so you might enjoy doing something similar.
One skill I tried to pick up in college was transposition (i.e. the process of changing the pitches in a song by some interval). This was a technique that was recommended to me as a way to get better at trombone. All I had to do was transpose my favorite piece into all 12 keys and keep playing it.
Having never actually attempted this, I don’t know for sure what the value of something like this would provide, but I can speculate. First, the process of transposition is likely not a skill you can do naturally. As a result, the process of doing it by hand several times may build up your skills to do it automatically in your head. Second, transposition provides a new piece of music on the other side which may test your range (e.g., highest notes get higher and lower notes get lower). Since you likely know the rhythms quite well, there is more effort that can go into developing your range. Finally, each key comes with a new scale that you can implicitly practice in a more fun way.
So, how does this map to programming? I think of transposition as solving a programming problem multiple different ways. At the end of the day, the program still does the same thing, so you can substitute any solution you’d like.
In terms of practice, this might look like finding a programming problem and thinking of as many ways as possible to solve it. I’m a big fan of this in general because it teaches you to respect different ideas and approaches. That said, it’s also a great way to learn. For instance, if you have a problem that requires a data structure, try solving it with different data structures. Then, for an added bonus, compare the results. Are all the solutions the same? Or do some run faster than others? How do they scale?
I’ve always been a “play it by hear” musician, so one of my worst skills has been sight reading. If you’re not familiar with this concept, sight reading is when you sit down to read a piece of music for the first time. Usually, I’d have to hear the music before I could play it. That said, if I could sight read, I could bypass the listening part altogether.
Regardless of how I feel about sight reading, more serious musicians would probably argue that it’s an important skill. In fact, there are a ton of competitions that include sight reading as one of the core competencies (see: adjudication). Outside of that, it’s just a nice skill to have, so you can get up and running quicker in an ensemble. Or if you’ve ever been in a small group, you’ve probably played a few songs live from an enormous book that you only practiced from once or twice (e.g. every holiday quartet ever).
From a programming standpoint, I could see sight reading being interpreted in a couple ways. First, there’s the skill of being about to read code and tell what it does. Then, there’s the ability to read requirements and convert them into code. I see sight reading a bit more like the latter. After all, you’re never really expected to play something perfectly when you sight read—it’s more like a proof of concept.
I suppose that’s where resources like HackerRank come in. Given a prompt for a random coding challenge, can you come up with a quick solution? The point being that you’re practicing the translation process between a set of requirements and actual code. Here, you’re not trying to write the best solution or even a good one; you just want a proof of concept.
For my programmer friends out there, how did I do? Did you pick up any new ways to practice coding? Are you interested in exploring music? Were you surprised by any of the connections I made?
For my music friends out there, what did I miss? Are there other practice techniques that you think can transfer over to programming? Do you do anything like this? How else has music helped your programming career?
With that said, that’s all I have for now! I’m interested in making this a recurring series as I have many different hobbies and interest. For instance, I’d definitely like to map programming and gaming sometime. Do you have any skills or hobbies that you’d like featured. Let me know!
Otherwise, thanks for stopping by. Feel free to take some time to stop and support the community here.