About music learning

a good advice when you want to play a new piece of music is to split the parts vertically and horizontally. Vertically is the simpler one, it’s just about splitting the piece in smaller temporal parts then learn and practice them separately. Horizontally is less natural for most people because we usually want immediately to hear our play sound like we use to ear the piece. It sound logical for most people to first lean the verses and then the chorus and later the solo from one side but after that cut you think that each part is small enough for you to immediately PAYEI (play as you ear it).

That’s an error, even great musicians will tell you that you have to gradually progress in your understanding and knowledge of a music piece, because it’s, by experience, the best way to learn. In other words, after taking each part of the song work on each horizontal slice:

• learn the notes and try to see how they could come to your fingers in the more natural way possible. Don’t care at all about the rhythm at this step.
• When you know the notes and that you’re fingers are trained enough to come naturally to their best position for the sequences, start to apply the rhythm slowly.
• Then, increase the tempo slowly until you achieve to feel good at the original tempo of the music piece.

Repeat that process for each part of the song.

Obviously if you’re a very good player and that you just need to play a song in public for a friend wedding or birthday maybe you can achieve that quicker. But, the point is that you surely will take more pleasure playing songs you really care and that are interesting to play (listening to something and playing it are two different concepts). For these songs you care about, you’ll certainly would like to do it right and need in this case to apply a slower and efficient process.

Another very interesting point is that playing a song is about memory, feelings and mechanics. When you play something, it’s not only about memory and you remembering the notes you saw on a paper (ok, maybe a screen now). It’s also about the feelings. The feelings connect you to the song, how to play smoother or harder and all the things that are not on the score, the emotions. The feelings are also about connection with the others, it’s your capacity to adapt your play because someone in the group just jump forward two mesures of the score and you have to catch him without people noticing the change. Feelings are something that you can’t learn in one day, and that some people have more than others, but that’s also something that you’re better each day with experience.

The last point is certainly the most interesting. I don’t know how, but our muscles also have their own memories. Sometimes you don’t know the notes, but trust your fingers they will know where to be. By training slowly and practicing a lot of times, your fingers, and body, will mechanically know what’s the next position. That means that even if you can learn very quickly a song before a concert or representation, you will forget it also that fast. Just like any other topic you lean that way, for an exam for exemple. That also means that the longer and slower you train, longer you’ll remember it because your body and mechanics will take over from memory when it will be faulty.

About programming.

at this point, if you try to read between the lines you may have seen some analogies with programming. Both are productions of the mind and it’s always interesting to see how others deal with complexity in things that have been here for hundreds of years and practiced by millions of people.

First, the vertical slicing is about feedback. The longer and complex the things are, more difficult it is to see the whole picture. If you try the process described in horizontal slicing to the whole song you just can’t make it. You can’t learn the notes of an entire song without rhythm without loosing your patience. You cut it in small parts, work on one and when you have the feedback giving you the information that this part is correct you can go to next one. That’s the same reason that pushes us to deliver frequently. We need to have frequent feedback that things go as they should.

Second, you have to practice slowly and regularly in order to get some automated mechanics. And yes, the more experienced you are, the more feeling you have about how things should be put in place. Some of us have a natural instinct to find the best solution for a problem and we can call that talent, just like for music, and for the others it’s something that we can also learn with time and work.

One less obvious thing that we can learn from music is the part where we first lean the notes, then apply rhythm and speed to obtain the expected result. The idea behind that is that you should start with very basic things, the obvious ones and let the code emerge for the more complicated ones until you have the expected result.

From a programmer point of view, I will describe that process like that:

• write a small piece of code that provide some value in order to learn and test how to achieve naively your goal
• add other pieces in the same way until you have a complete feature as expected
• when you have a global vision, improve your code by refactoring it, tuning it.

The important thing is that it’s very difficult to write good and efficient code that do exactly the job and without over-engineering it. And yes, you can start writing crapy procedural code if it’s the best way for you to learn the best to produce a functionality before refactoring it with better object oriented or functional code.

I wrote awful procedural code that went in production, and then after some time, because of experience and new learnings about patterns and practices, I wrote nicer over-engineered object oriented code that don’t fit very well business goals.

I was not very happy with that. Just like when you do a concert, and don’t learn and repeat the songs enough and in the end you’re not happy with your play. At the end, that doesn’t matter because most of the audience don’t understand music and is not able to see how you failed. But YOU know the shit you did, you know why and you’re responsible for it. At some point it’s the same with the programs you deliver for end users that don’t know about programming…

Most of the time we act like that because all in all we’re lazy and we like recipes that we can apply every time without thinking.

What we usually miss is that it’s important to slow down our production of code and listen more to what the code is telling us.

My last advice should be then:

• Learn,
• Listen,
• Refactor,
• Practice.

And yes, TDD and other practices are valuable tools if you apply them in their essence and not as a blind dogma.

happy code in music!