In my last post on this topic, I looked at some of the commonalities between learning to play a musical instrument and writing software. In each case, there are “rudiments” to be learned, boring though they may be, that help one become great at either craft. In this second installment, we’re going to look at what happens when you’ve finally learned to play and decide you’re ready to take the next step: Composition.

Finding Your Own Voice
There us a huge difference between playing the notes written on a page and making music. When we find a piece of music we really like, more often than not it’s the feel of it that draws us. More than the simple, linear arrangement of notes or chords, it’s the interpretation of those notes through the act of performing that makes a simple sheet of musical notation actual music.

For many musicians, this is more than enough. But for some, the satisfaction of simply playing music written by others wanes quickly and they seek to find their own voice, to express their own ideas, their own reflecting glass for their experiences. So they turn their energy to musical composition.

To be a successful songwriter or composer, you need:

• Experience: First and foremost, you must have mastered the art of playing music before you can master composing music. I’m certain that this is an arguable point (I’ve never seen a point that wasn’t), but in my experience, those who can’t play generally can’t write very well either. They tend to have unrealistic expectations of the musicians that will need to take what they’ve written and perform it. They also tend not to have a good feel for what musical structures fit well together and sound most natural to the human ear. It’s that sense of recognition and comfort, after all, that differentiates what people consider music from background noise.
• Creativity: This seems like kind of an obvious one, but you’d be surprised how many people I run into that try to write music based on an astoundingly detailed knowledge of musical theory. Certainly, theory provides you with the tools to understand the what of music, but the how, and more importantly, the why must come from the mind and imagination of the composer. Without creativity in composition, we’d still be listening to waltzes and chamber music, the lute would still be the string instrument of choice and percussion would be optional (though some may argue it is anyway). Human creativity pushes the envelope and fosters an environment where the art can evolve beyond the status quo.
• Knowledge: This is related to experience, but is slightly different. Imagine you’re composing a piece for a major symphony orchestra. Think of all the individual instruments for which you’d need to write parts: Violins, violas, cellos, basses, winds, brass, percussion, etc. And within each instrument group, you need to write the first part, second part, etc. If the only instrument you’ve ever studied is the clarinet, then you’ll likely write a fantastic clarinet part, but will likely find it very difficult to successfully write all the other parts in a way that leverages the strengths of each instrument and creates one unified piece of music. Understanding and knowing the composite parts of the larger ensemble of instruments will certainly lead to a more cohesive and sonorous piece of music.

The Composition of Architecture 
Musical composition clearly has parallels to the software development process when you consider the role of the architect, vague though the definition of that role can often be.

In my experience, I’ve found it very unusual to see successful architects that didn’t start out, in some capacity, as software developers. What I find to be the case more often than not is that the best developers on a particular team gravitate into the role of the architect, either de facto or de jure. I can’t speak for all architects that followed this particular career progression, but I can speak for myself.

I was drawn to software architecture for a couple of reasons:

1. Writing software handed to me and designed by someone else started to hold less interest day-to-day for me
2. I felt I had good ideas for designing systems and wanted to be in the position to express them

In other words, I wanted to stop just being a “performer” and wanted to become a “composer” because I saw it, primarily, as a venue to better express my technical ideas. That being said, I still code as often as I can (which isn’t very often these days, but I do find time now and again). I’ve never met a composer who didn’t continue to play on a regular basis, even though it wasn’t their primary vocation. We do this because it keeps us sharp and in touch with the ultimate results of our work. If we can’t play it, it will be difficult for others to play it. Some of the worst architectural designs I’ve seen have come from architects who never paid their dues in the trenches writing code and making software work on a real project. I once had a friend who told me, “True wisdom comes from great pain and suffering.” Over the years, that dictum has been proven true time and time again.

I think that creativity is one of the most overlooked characteristics in successful software developers and architects. When we think of people who work in software, it’s easy for us to picture the long-faced nerd with an overbite, thick black glasses and a picket protector tucked into the front of wrinkled white dress shirt, purely analytical and socially inept. While the industry certainly has its share of those archetypal individuals, it’s also filled with mainstream, highly creative people who simply love the malleability of software and the ability to make it into just about anything you want or need it to be. Like music, software architecture has “theory” (we tend to call it “best practices”) that, if followed, get you moving in the right direction, and ultimately it’s the creative use of those guidelines that allow new ideas, techniques, and yes, best practices to be tried and vetted. It is creativity, I think, that makes a lot of musicians and other folks with artistic backgrounds who work in the software industry so successful. Because the tenets of theory are more guidelines as opposed to hard rules, musicians tend to be more comfortable experimenting with things that haven’t been tried before. Musicians don’t have a corner on the creative market, of course, but for the most part they have active, creative minds that can drive the “next big idea” to make developers, architects and the products they produce better. When you stop to consider something like test-driven development (TDD) and the progenitors of that movement, it’s easy to see the important role creativity can play in building better software. Many people would call this “Thinking outside the box.” A creative approach to developing software precludes the idea of a box in the first place.

Certainly, the role of knowledge in software architecture should be self-evident. In this case, it also warrants a discussion of its own and will be the topic of the next and last post in this series: Teaching.

It’s always striking to see how many of our colleagues in the software industry are musicians. That fact occurred to me last week as I went to jam with some guys I’d never played with before. The lead guitarist walked over to me as I was setting up my kit and said, “You work for Microsoft, right?” and so began a twenty minute conversation about how he had worked in IT for years before retiring and going on to teach and play guitar full time.

Everywhere I travel, I find software developers and architects who moonlight as musicians. I’ve been thinking a lot about this lately and think I’ve discovered why so many of us sit in front of a computer keyboard by day and a piano keyboard by night: The act of learning and playing a musical instrument requires many of the same mental attributes and skill sets that are essential to being a good software developer. I’ve decided to explore this topic a little deeper in a series of posts. This being the first, we’ll focus on the building blocks of both skills: Technique.

Learning to Play 
I started playing the drums when I was eight-years-old and in the third grade. I can still remember my first band practice at school, holding the huge pair of standard issue Ludwig concert sticks and hitting the solid steel Ludwig concert snare drum my parents rented for me (secretly hoping all the time that my desire to be a percussionist would soon fade, I’m sure). The first thing we learned to play were the 13 essential drum rudiments. These are the building blocks of playing the instrument and are excellent exercises for building coordination and speed. The first one we I learned then, and most percussionist still learn today, is called the paradiddle.

The paradiddle is repetitive pattern between the left and right hands. It looks like this: R-L-R-R-L-R-L-L. Go ahead, try it. I know you want to.

When starting to learn this rudiment, you begin the pattern slowly, focusing on keeping each stroke even with the next at a steady tempo. When this initial slow tempo feels good, then you gradually speed up, continuing to focus on evenness and tempo. If your strokes start to become uneven or you have trouble keeping up the tempo, slow down until things get better and then, gradually begin to increase in speed again. Here’s an example:

While learning this first of many rudiments, I was also instructed in how to properly hold the sticks in my hand:

• Let the stick sit relaxed in your hand
• Use the rebound of the stick off the drum head to help propel the next stroke
• Use your fingers to catch and manipulate the stick
• The stroke comes from snapping your wrist, not your arm – you’ll never get speed using your arms

I was getting all this instruction while still having to think the pattern “R-L-R-R-L-R-L-L” consciously. This was really hard to learn in the beginning. I was teaching my body to operate in a way it never had before, wiring up nerve paths that didn’t exist, and trying to maintain a level of discipline to make it all happen. The last point proved to be more difficult that the previous two.

As with any learning experience, you have to learn the basics before you can move on more advanced techniques and concepts. Let’s face it, practice the rudiments can be really boring, but they help you build the technique you need to take your skills to the next level. And the commitment you show to practicing the basics has a direct correlation to the level of your success. Are there exceptions to this rule? Always, but they are very rare.

Learning to Code
So, what’s the correlation to learning to code? As I detailed in my software development meme, I don’t have what you would call a traditional background for someone who does what I do for a living. I started college as music performance major and then switched to English literature, in which I went on to eventually earn a Master’s Degree. Coming out of graduate school, newly married, I found the job market somewhat lacking in open “poet” positions, so I went back to my old hobby, computer programming.

Truth be told, I learned to write software in “the modern era” by purchasing books like “Teach Yourself Visual Basic 4 in 21 Days” and “JavaScript Unleashed.” We laugh about those kinds of books these days, but back then, in the pre-WROX days, those were great learning tools available conveniently at my local Borders. I was working a fulltime job, so I spent hours and hours each night after my wife went to bed sitting in front of my Windows 95 PC doing exercise after exercise, learning language syntax and form:

• The things I use in the user interface are called “controls,” and their behavior is controlled by “events”
• Objects represent entities specific to my application or business problem – their actions are called “methods,” their descriptors are called “properties”
• Text data is handled as a “string,” numeric values can be “short,” “int”, “long,” “double,” etc.
• SQL is the language you use to communicate with databases

Of course, these seem ridiculously natural to us now, but at one point, all of these concepts were new. They’re called “rudimentary” because these concepts are the building blocks of what allow us to write applications, just like the mastery of the paradiddle contributed to my becoming a better drummer.

This was me learning the technique of software development. Like learning to read music, which is itself a new language, I was learning the rudiments of software development. And just like their musical counterparts, these rudiments don’t automatically make good software. Without a fundamental understanding of structure, style and yes, art, software is just a series of lines of code stacked one on top of the other. The more you practice the art, the more you learn about how these rudimentary concepts coalesce to create something greater than the some of their parts.

And thus is the transition between the rudiments and the final product. Music is more than just playing notes on a page. It’s weaving those notes together and producing something musical with them, like this alteration on the simple paradiddle when I sit behind my drum kit:

Likewise, writing software is more than just slapping code onto the screen. Your code is built into a larger structure and constructed carefully to maximize performance, user experience and maintainability. This is the quintessential art of software development, and one of the reasons why I think so many creative people are drawn to software in the first place. Like music (and most other forms of art as well), programming marries the strengths of both hemispheres of the brain. The analytical, pragmatic mind enables and facilitates the creative vision, providing it the tools it needs to be realized. Thus, technique evolves into proficiency and, eventually, mastery.

So, what happens once we practice the rudiments and become proficient artists? In my next post, we’ll explore the similarities of musical composition and software design.