betwixt code and music

Out of Practice

(3 min read)

I have noticed a funny thing as of late. In music-making and writing I am out of practice. This is a cautionary tale of awareness and a possible solution to being out of practice.
Musicians have long heard the phrase "practice makes perfect." It is a silly phrase. One can practice for a year straight and be extremely excellent at doing something wrong. A better phrase is "perfect practice makes perfect." Yes, this is something I have said to hundreds of students over the years.

Malcolm Gladwell in his book
Outliers espoused the "10,000 hour rule." Many people immediately became champions of this. The idea is that the difference between an expert and the rest of the herd is simply putting in the time—ten thousand hours according to Gladwell. Again, this amount of time spent holding your violin incorrectly will still lead to a situation of being super great at holding your violin, but now you are doing it incorrectly.

A more prudent approach is to make sure one is engaged in deliberate practice as told by
this gentleman Anders Ericsson. This "on purpose" approach is key to getting better at one's discipline. This is where having a guiding hand in a teacher or a mentor provides value. Let me revise that statement. This why a teacher or a mentor makes all the difference in the world, especially for someone new to a discipline.

"Mike, you are getting heavy. I thought this blog was supposed to be light and fluffy."

Well, sometimes it is…but not writing for five months means I have been building up steam!

Over the summer I had the cool opportunity to take some time off from my software development gig to teach music. I spent two weeks teaching a local high school drum line in the afternoons. Another week I spent Monday through Saturday teaching a college percussion section.

"Whoa, man. All this time we thought you retired/moved on/abandoned your love of teaching!!"

Not at all, I just wanted to do something that was still creative, engaging, challenging, but more flexible and didn't have a capped salary range.

As I was dusting off my drumsticks to go teach these three weeks in the summer, I realized some things. My chops and brain were as good as ever…but I had become out of practice. The daily repetitions were no longer part of my routine.

Thankfully, I
knew what I needed to practice to get my hands/arms back in shape, but it wasn't something that came immediately back. Keep in mind I had been drumming with my classes daily for over a decade with little time away from the discipline. With my fairly wide knowledge of practice routines, I was able to get my hands back into a decent form with minimal effort. (Shout out to Jonathan Ovalle from the University of Michigan and his old snare drum warmup routine, sadly now removed from his website…good thing I made .pdfs of them long ago!)

You might be wondering how I managed to get my hands back in shape with very little time.
Deliberate practice. It is much better to spend ten minutes working on a specific skill or muscle group than just playing all of my favorite licks from time past. This approach was validated when I stood in front of college-age musicians and could easily hang with them. Now, this is not a truly objective test, I will admit. My expertise in drumming is already high, I had just lost some of the skills.

The takeaway: you
can get better at your skills by doing lots of reps and practicing routines on purpose, with good form!

Hey, folks, this applies to more than music! Not great at budgets or typing or gardening or laundry or coding? Then make a plan to figure out what to focus on first and
GO FOR IT! You might just find yourself moving into expert status before you know it.

Re-learning Problem Solving

or Remembering how to learn

Let's go to inspect element and see what that is.

What is the type of that variable?

And what type is the data inside of it?

Do you remember how to iterate over that kind of data?

These are all phrases that our patient teacher Aaron has doled out repeatedly in class and one-on-ones. I will go ask for a hint on a problem that is blocking me, and these phrases (or ones like them) appear. This post is partially so I will ask myself those questions later on when an experienced programmer is not sitting 10 feet away. It is also to remind myself that problem solving from one discipline to another is similar. I should not have to re-learn everything about problem solving.

image from

In music (it always goes there with me), and especially as a music educator, I am acutely aware of the inherent problems of the activity. If you pick up a trumpet for the first time ever, making a sound at all poses a significant problem. With the help of an experienced teacher, a student (young or old!) can learn to form the face and fingers correctly to begin to make sounds. With a consistent approach to practicing, the struggles of producing sound lessen over time. Concurrently, a student should be learning to read music - to interpret all of the black and white of the page into sound. Thankfully, there are millions of people undertaking this problem-solving everyday, and we are the richer for it. Hearing a great musician, or even a group of them, remains a favorite activity of many of us for good reason; there is really nothing quite like it.

I am finding a similar approach necessary in programming. There is the hurdle of simply using the software and hardware: which program do you use to write code, how do you use the command line, git and GitHub, browser developer tools. For a long-time computer user like myself, this is mostly a non-issue. I learned to type in high school (though I still go too fast and have to use backspace way too much). I loved messing around in ms-dos back in the day, so using bash isn't terribly different. Using git and GitHub has proven to be a bit of an obstacle, but it is improving with daily practice.

The deeper issues are found in the complexity of programming. I would liken this to reading music and interpreting the notes and rhythms into sounds... not just "Three Blind Mice" and those beginner songs, but the more challenging ones that turn out to be very complex.

I recall learning the beginning of the famous song "Merlin" by Andrew Thomas. It is a solo marimba piece written in the 1980s which is very complicated and amazing to behold. Even looking at the music is daunting. This little snippet is merely the beginning of the second movement.

linked from www.nancyzeltsman.com

Several issues:

  • The notation is handwritten which may make it more challenging to read for some people.
  • The grand staff is in use, so the performer will have to know both treble and bass clefs
  • It is in 6/8 time signature, but you cannot tell that when listening to it.
  • The volume changes rapidly from very soft to very loud, so the performer has to be able to control dynamics.
  • In measure three the notation begins to separate the hands across the grand staff, which makes it more challenging to read.
And this is just the beginning of the piece - we didn't even discuss what it takes from the hands to perform the techniques!

In programming, we were recently presented with a similar kind of problem. We needed a framework of rules and understanding of JavaScript to begin to tackle hoisting exercises. I will readily admit that I am still not always getting these 100% figured out, but I am coming closer. Here is an example of one of our first exercises in learning about hoisting:

var myvar = 'my value';

(function() {
    var myvar = 'local value';

For this kind of problem, one should know what the keywords
var and function mean in JavaScript. They are declaring a variable and function, respectively. This is akin to pointing at a dog and saying, "There is a dog." In the var declaration, everything that comes after the equal sign is like saying, "That dog is named 'Ewok'". The variable becomes useful only after it has been declared (pointed at, in my example) and then initialized (named "Ewok").

Easy enough to understand, yes? The strange part is the way that JavaScript behaves concerning these different things. The declaration of variables and functions happens before they are actually named "Ewok." In the example, the self-invoking function gets hoisted to the top. JavaScript says, "There is a function" and puts it above all other code. When the code tries to access the name of myvar inside the function, it does not know where to find it because it has not been properly named yet.

Little tricks like this are the little mental hurdles to jump in order to write effective code. We must always know how our programming is
really working. What kind of data lives inside myvar? Is it a string, a number? How do we deal with that data? When we combine that piece of information with another data type, then what will be the result?

The more I get into this, the more it resembles the real issue of learning a piece of music. We learn myriad ways of solving problems, then we work on using those in different ways in each piece of music we perform. Each piece of code is different, depending on which problem is meant to be solved by it. I have to do a good job of getting consistently good practice in both understanding the language's quirks and working on interesting problems.

As a side, yesterday I went to watch a rehearsal of the marching band from Vista Ridge High School in Cedar Park, Texas (to the northwest of Austin proper). There are many problems to be solved in marching band where the students are dealing with moving in different directions, performing different music, while carrying a heavy instrument (if you disagree, then go strap on a sousaphone or a bass drum for a few minutes!). As I no longer get the daily thrill of being around a group of 200 young people working in unison, I hope that my friends that experience that often do not take it for granted. The band I saw is one of the best in the state of Texas, and it was a pleasure to get to see their product and give my input to help solve any problems I noticed.