Code in music: What the piano can teach you about programming

#beginners #programming

The holiday season is here!

Like every year in December, there are two things you just can’t escape:

Advent of Code if you’re a programmer.
*ingle Bell Rock if you step into a shopping mall.

That’s just how it is—I don’t make the rules.

Advent of Code is all about programming puzzles, kind of like what you find year-round on LeetCode. Its stated goal is to make you a "better programmer." And I do mean programmer, not developer.

So, how do you become better at programming? Should you be grinding LeetCode every day? I’ve never had to implement a merge sort at work, so do I really need to learn it?

Whoa, slow down!

Speaking of which, did you know that piano means "slowly" in Italian? Perfect segue, because before we dive into programming, let’s talk about piano. Don’t leave just yet—it’ll be worth it.

Playing the Piano

When I’m not behind a computer keyboard, you can probably find me behind a piano (keyboard, piano, computer—you see the connection? Alright, got it).

And funnily enough, learning piano offers a lot of parallels to programming.

What does playing the piano involve? It’s not about memorizing the name or sound of every single key. (You generally know where C is. From there, based on your hand position relative to C, you know what notes to play. But you don’t necessarily need to know exactly where A and B are, for example.)

Playing the piano means hitting the right notes in the right rhythm. It’s really a combination of the two. If you play random notes, you’re just making noise, not music.

If you hit the right notes but leave 10 seconds of silence between each, you don’t have music either—there’s no rhythm.

To improve these two skills, there are various exercises. For hitting the right notes, you might play very slow-ly, ignoring rhythm entirely. The goal is to figure out: the note to read on the sheet music and the finger to use to play it. Sometimes your hands will need to move, so you also practice repositioning them. To build muscle memory, you play several notes or melodies slowly—very slow-ly.

For rhythm, you play simple notes or sequences. The goal isn’t to play a melody but to hit the notes within the allotted time.

As you improve, the exercises become harder, but the ultimate aim remains the same: to eventually play a piece by combining note accuracy and speed to maintain rhythm.

When you’re at an intermediate level and play a piece for the first time, if it’s simple (a children’s tune, for example), you can play it almost perfectly on the first try or with minimal practice.

But if you attempt something more challenging (jazz, for instance), you’ll need to do more exercises for note accuracy and rhythm specific to that piece.

Another interesting point: you can learn to play a demanding piece, not touch it for a few months, and then try again. You’ll probably be terrible on your first attempt, but you’ll quickly regain your footing and play it perfectly without redoing the entire learning process.

If you want to improve at piano, you’ll also need to step out of your comfort zone. You can stick to children’s tunes your entire life, but that won’t help you play jazz later without practice. You need to play different styles, of varying difficulty, and with diverse rhythms.

In summary, to learn piano, you need to:

Practice various exercises to improve the different skills required for playing music.
Play diverse pieces with increasing difficulty.
Occasionally revisit older pieces to quickly regain your footing and strengthen your muscle memory.

And Programming?

Well, it’s the same.

That's it, thank you for your time, see you next soon!

And Programming?

Well, it’s the same.

Puzzles like LeetCode are like little melodies. To solve them, you need to use the right data structures and algorithms (the equivalent of piano notes) and do so within the given time limit (our rhythm).

If you’re tackling a LeetCode puzzle involving a merge sort for the first time, you should start by learning—outside of the puzzle—what a merge sort is, how it works, and how to code it. Slow-ly. Then, you can try solving the puzzle within the time limit. At first, you might exceed the limit, but with practice, you’ll hit the right rhythm.

Once you’ve nailed that exercise (the right algorithm, at the right speed), you can explore other puzzles—other melodies. Some will be similar, others not. Increase the difficulty to progress, but don’t expect to succeed on the first try. That’s not the goal.

Revisit them a few months later (for a project or an interview). You’ll find that while your implementation might be a bit slow at first, you’ll quickly regain your footing and solve the puzzle within the time limit again.

I’m a Pianist, Not a Musician; I’m a Programmer, Not a Developer

Now, do coding puzzles make you a better programmer? If you do them regularly, probably yes. But do they make you a better developer? Not really, because that’s not the same thing.

If I play piano, I can play Jingle Bell Rock at home without issue. Great, I have a good time, and it adds a festive vibe. But playing piano doesn’t teach me to:

Compose my own music.
Play with other instruments.
Perform in an orchestra...

In short, lots of things. Playing piano doesn’t necessarily make me a musician. I’m a pianist—a hobbyist pianist, and that’s perfectly fine.

Likewise, being good at programming doesn’t make you a developer (the profession). It doesn’t teach you to structure your code, write documentation, or do many other things engineers need. It simply teaches you to solve programming puzzles.

Sure, some problems might be reusable in a professional setting (I work with tree traversals like DFS and BFS quite often, for instance), but that’s anecdotal compared to everything else I do on the job.

Happy holidays! If you’ve got Jingle Bell Rock stuck in your head now, you’re welcome. 🎄