In the Tech team at MarketInvoice, there are several members who play musical instruments ranging from the guitar to the tuba. A quick survey showed that approximately 35% currently play an instrument, 35% have in the past and 30% haven’t ever. This brought up some interesting questions. Is there a relationship between the two areas? What sorts of overlaps are there? In this blog post, I’ll discuss some of the similarities between working in tech and playing an instrument.

Debugging music

As an engineer working in tech, debugging is a recurring task. One of the first steps that needs to be carried out is to identify and isolate the sections of code that are causing it to break. After a broken section is identified, say a class or a method, it can be quarantined, split up further into subsections and scrutinised until fixed. This is often done in a cyclic fashion until all the bugs have been removed and the code is working as intended. Tests can then be implemented to prevent similar problems happening in the future.

When learning to play a piece of music, it is unusual to be able to play it perfectly (if this exists) the first time through. It is often the case that some passages are more challenging to play and, as a result, require more practice. A common method of practising such sections is to play them individually in isolation, separating them into further smaller subsections and playing these slowly until they can be played independently. After that, they need to be integrated into the piece so that the music flows seamlessly.

Exploratory melody analysis

In Patty McCord’s book “Powerful: Building a Culture of Freedom and Responsibility”, she mentions that the HR team at Netflix used to get excited when a person who played an instrument applied for a Data Science position. The reason being that data scientists who had a keen interest in music had performed well in the past. This was thought to be because playing a musical instrument helped them to toggle between the left and right side of the brain (a useful skill for data analysis).

Music smell

There is a clear distinction between being able to play a piece of music and being able to play it well. When performing a piece of music, the musician needs to be able to play the correct notes, but also needs to consider the dynamics the composer has written, the tempo, the phrasing and the style of the music.

Similarly, functioning code and well-written code can be very different. Code that works can be poorly written so that it functions for its purpose but is inefficient, hard to read or not reusable. These types of attributes are sometimes referred to as ‘code smells’ and can be the cause of lots of future issues. For example, minor changes to the scope of the original problem could result in ‘shotgun surgery’ being required to adapt the code to the changes.

Test driven performance

A common phrase used within music is “don’t practice until you can play it right, practice until you can’t play it wrong”. A previous music teacher of mine used to teach the method of playing a passage or piece of music six times in a row without making any mistakes to reflect this phrase. If there were any mistakes at any point, the passage where the mistake was would be practiced in isolation and then the process started again. This reminds me of the software development process Test Driven Development (TDD) used widely in the tech community and here at MarketInvoice. The focus on tests in this approach helps an engineer to think of different possible scenarios. This is so that the code works for all cases, as opposed to working for one case and breaking in others.

Orchestrating the codebase

Working within a tech team could be compared to playing in an orchestra. In an orchestra it is important that all the musicians can play their parts individually. It is equally (if not more!) important for them to be able to play in time with everyone else. They also need to make sure that they are in tune relative to the orchestra, play within the context of the piece and performance and are always aware of what other members of their section and the wider orchestra are playing.

A tech team normally consists of several functions. For example, at MarketInvoice we have engineering, product, UX, and data science. A project might require work from multiple subteams as well as external and internal cross-functional stakeholders. It is therefore not enough for a member to focus solely on their own tasks; they need to work collaboratively with everyone else. A team might also have certain design patterns or development processes that they abide by, and it is important for a member to adapt their own style to that of the team’s.

Coda

It is clear that there are similarities between playing an instrument and working in tech. Some of these similarities could probably be generalised further into other domains such as academia or sport but I believe there is a particularly close association between the two and hope that this post reflects that.

If you’d like to chat about engineering (or music), get in touch by emailing p.callery@marketinvoice.com.