Recently, we looked at how a jazz combo is a great metaphor for the interactions and exchanges that make up a great small team. The question then comes to mind, “surely, isn’t there more to it than that?” The answer is an unequivocal yes. There is quite a lot to it. Groups that reach this level of comfort and collaboration have a lot of experience and expertise under their belts. Let’s start to explore the journey that gets us there.
When I was a kid, I was very lucky in my music education. My high school was the host to an annual jazz festival, featuring all of the local high school and university jazz bands. Because of this, I was exposed at an early time to a lot of different styles and techniques for music. The festival was actually prestigious enough to be able to attract some top named talent each year who would give a concert and workshop. We had folks like Dizzy Gillespie, Louie Bellson, and Clark Terry work one on one with us. This was the opportunity of a lifetime, and it happened once a year!
I’ll never forget the first workshop. Here I was a young high school student. I considered myself a pretty darned good player, but I was going to learn from one of the founders of the bebop movement, Clark Terry. This was a chance to get past all of the usual, boring stuff all of the teachers told us, and get into how jazz is really made. Mr. Terry had us play a little, went over a few things, and then asked if anyone had any questions. I asked him how I can really improve my soloing skills.
Now before we answer this, I should take a small detour for those who may not have ever been involved in jazz. During each song, there is a break where certain players will get in front and improvise. No music is written down, just the chord structure(some might say architecture) of the song. It is very challenging and intimidating at first, but absolutely the most fun you can have once you learn how.
Now, where was I? Oh yes. Clark Terry was about to teach me the secret to great jazz improvisation. He looked at me and said “Learn your scales, man.” What? Learn my scales? Scales are about as basic as it gets. Once you learn how to make noise without making the dog howl, you move on to scales. No real songs just up and down in each key. Guess what? He was right. I know, big surprise a jazz legend was right about how to play jazz. Once I learned those scales so that I wasn’t “thinking about what to play next”, the improvisation came easy. I was merely playing something that “felt right” because the actions and structures of those scales were burned into my subconscious.
Programmers need to do the same thing. Once we learn the basics of control structures and loops, we need to learn our scales. It is not enough to just learn them once, or read about them in a book either. We must practice them every day. We apply them to the work we do, and we aren’t willing to compromise on their quality. The more we do this, the more natural it becomes. Just as I might not consciously say during a solo “now I am going to play a B-flat minor with a diminished seventh” I might not while writing a piece of code “and now, I will implement a strategy pattern”. I will obviously be aware of it, but it will be so built into what I do as a programmer that I won’t have to stop and think about it. My awareness will be built into what I am doing.
So what is the programming equivalent to scales? There are actually a few activities that I feel fit into that category. Most of them are discussed quite often but lets take a look at them again.
Test Driven Development
Writing a test prior to writing your code is not very controversial anymore. Everyone recognizes the value in doing this. And yet, most programmers will maybe write a few tests to get started, but then quickly move to an attitude of “I don’t have time right now, I’ll get to them later”. This is totally understandable, since the idea of writing tests first still feels counter intuitive. So do minor scales. It takes repetition and practice to get this activity into our “muscle memory”. Sometimes what we are doing is uncomfortable, or feels like it is wasting time. We do it slowly at first. But over time, it becomes an instinct.
This instinctive activity is not going to happen just by doing it at work either. Just as Uncle Bob Martin asserts in his latest book Clean Coders, we need to practice at home also. Find a project or site where you can practice writing tests and making them pass. Get used to the idea of writing a test and then working to the “green bar”. We’ll talk more about practicing in a later post, though. Suffice to say, you need to practice, and a true professional will practice at home.
SOLID
Another form of scales is Object Oriented principles. The best description of the principles that lead us to true success is the acronym SOLID. This has been identified and explored in many forums, so I will only briefly touch on them. For a deeper dive, I would refer you to Robert C. Martin’s book: Agile Software Development, Principles Patterns and Practices. Here is a link to an early article he posted on the subject. Meanwhile, for your dancing and dining pleasure, here are the SOLID principles, in brief:
Single Responsibility – An object should have one and only one reason to change.
Open-Closed – a class should be open to extension, but closed to modification.
Liskov Substitution – Derived classes must be substitutable for their base classes.
Interface Segregation – Clients should not depend on methods they don’t use.
Dependency Inversion – Modules should depend on absractions, not details.
One interesting parallel to our musical paradigm here is that, as you start to get very comfortable with staying within these principles, you start to notice things that are not quite right. You are so used to looking at code that fits within the SOLID principles that it just seems natural. Code constructs that violate these principles come across as out of tune. Something we refer to in music quite often as “klunkers”.
Patterns
The final scale I want to talk about is Design Patterns. Patterns are another part of our basic language. We need to work with them, and be comfortable with them. I am not a huge fan of saying “Here is a problem, which pattern shall I apply to it?” That feels artificial to me. However, I also remember a time when I was just learning music that I did consciously say “Now I am going to play notes from the B-flat blues progression”. As we are using patterns, we become more comfortable with looking at a problem and just knowing what we are going to do to implement it. Later, as we are discussing it with someone, we will note that what we did was apply a Visitor pattern.
So, in conclusion, even though it isn’t anywhere near as much fun as just going out there and soloing, we need to learn and practice our scales. It isn’t enough to read about them once, or to pull them out of our bag of tricks when we have enough time or remember to use them. They need to be a part of what we do every day, and they need to be so ingrained in our brains that we don’t even notice when we use them. Hey if its good enough for the greatest performers and innovators who ever lived, surely its good enough for us. Now I gotta run. I gotta go practice.
Hey what about Refactoring? Refactoring is hugely valuable and extraordinarily important. It is so important that I want to save if it for next time, when we talk about Practicing.