Music, Beam Notation and Test Driven Development?

I usually consider it to be blasphemy when music and code practices get mixed together under the same breath, not to mention a full post, so you can imagine that what I’m about to share with you next is much of a new perspective for me as it might be for some of you.

I play music since I can remember myself. Started at the age of 7 playing the classic piano and moved on to the guitar at around the age of 12, which I am still playing to this very day. I read and understand notes and consider reading notes a must for anyone who wishes to become a better musician. You see, it is like only being able to speak your ideas vs. writing them up. Unwritten ideas have a tendency to slowly fade away while written ones… well, I can think of a few books which revolutionized humanity. can’t you?

Musical notes are a musician way to share their music. It is our way of describing complex musical ideas, break them up into parts, explore and learn more how we can express our minds. Same goes for code.
But what sadly differentiate the written code from the written music is the composer’s reluctance to make his ideas more approachable and understandable to others. in music, the easier your fellow musician can read and understand your work the faster he can join in and play with you in a beautiful harmony and that’s what it’s all about in the end, no?

Once again — same goes for code…

how does a music composer make you read his notes easily? well, one common technique is to divide the notes in a single bar into rhythmic sections and use “beams” to express it on the score. 
Say you have the following bar:

Where is the… wait a sec…

Well, I hope my music teachers won’t see this :)
It is really hard to understand the beat here. It has four by four time signature which is the classic rock/blues signature, but its hard to read and play immediately for the player needs to work hard in order to understand how each note falls rhythmically. 
Lets try it another way where each group of notes represents a rhythmic unit:

Oh — much better!

Musicians look for the time signature units, since reading them one after the other is much easier. Here, I’ve even marked them on the top with numbers, though it is pretty obvious since the note-beams are grouping them together.

You’d be surprised but this reading process resembles the reading code process quite a bit. Code which is divided into functional units is much easier to read and dive into than code which isn’t. The difference can be dramatic.

Whilst writing music score without practicing beams is considered a “crime” in the eyes of any musician, somehow writing code which is not divided into functional units is ok.

This is odd since the motivation of the composer in both cases is for everyone to play together in a perfect harmony.

A great way to produce code functional units is to (here it comes, you’ve guessed it) practice TDD. Not just write unit tests, but write them first.
When writing unit tests first, you define the unit, which is the functional “beam” of the code. This will also encourage you to think how your functional units will work together, and eventually the next coder looking at your composition will enjoy diving into your code.

I’m might be stretching the analogy here but I always feel that the code I’m reading has a certain rhythm of its own. I can tell when I’m reading a cacophony of notes and when I’m reading a beautiful piece of a master. I’m pretty sure you can tell that as well…

Write code others can read.

If you enjoyed reading this, please click the ♥ below. This will help sharing the story with others. Cheers!

Like what you read? Give Matti Bar-Zeev a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.