Once upon a time in college, I was faced with a dilemma - do I wish to professionally pursue music and drumming or computer science? When discussing this dilemma with others, I was often met with a chuckle, being asked, "could you have picked two more different majors to be split between?" In the end, I started as music education, and switched to computer science. Over the following years, I noticed something strange - I was joined in my CS classes by more and more musicians, especially drummers, and more and more of my CS peers disappeared only to be seen again in passing in the music building. What was going on?
In the end, I was ultimately referred to DealerOn by a fellow drummer/software engineer hybrid. While that was fairly mind blowing, what's more mind blowing is that today, on DealerOn's development team of ~40, we have 8 drummers. That's 20% of our team. What's going on?
I believe this is due to two factors: first, the shared natural inclinations that contribute to success in both, and second, the lessons learned due to similar challenges in both.
It should be of no surprise that software engineering requires an affinity to math and logic. Perhaps more surprisingly to some, music - especially drumming - does as well. Rhythms represent complex mathematical structures across time. These structures, written in sheet music, are interpreted into the product: music to our ears. This is not dissimilar to programming algorithms, which are interpreted into the product: software.
These products represent the next similarity: creativity. Both music and software development are creatively applied mathematics. Both require both creativity and design: creativity at the base level of writing code and sheet music, and design of your product in the big picture, whether that picture is your vision of a software product or a song. Being able to take these cold, mathematical abstractions and use them to create awe-inspiring products is at the core of both passions.
On the other hand, most developers and drummers find a certain amount of comfort and pleasure in the absolute truths that coincide with the creativity. Coding is bounded by certain concrete rules and truths, peacefully coexisting with more flexible creative decisions. Drumline is bounded by some strict rules of interpreting rhythms, movements, and dynamics, peacefully coexisting with creative liberties and endless possibilities. In both, our experiences, personalities, and values shape the creative liberties and decisions made.
Conway's law states that teams "are constrained to produce designs which are copies of the communication structures of these organizations."
To this, there are huge organizational similarities to musical organizations (such as drumlines) and software development teams. In a drumline, there are multiple sections - cymbals, snare drums, bass drums, tenors - all of which have to operate independently to create their individual product, while aligning goals and vision with the greater whole of the drumline, which must align their goals and vision with the greater whole of the band. This is similar to a software development team working on a given system, which develops their product as part of a bigger infrastructure handled by the larger team, which also must align with the company's goals. These experiences create unique challenges and lessons which inform one another.
These learning lessons arise out of necessity due to the inherent sense of ownership in drumline and software development. Both have tiered leadership, at the individual, sub-section, section, and whole level. If an individual fails to complete a task, it directly affects everyone at all levels above and below them, resulting in a direct sense of responsibility to the greater good. These smaller sub-section teams create more opportunities for everyone to experience leadership in some way, whether that's in creative leadership, ownership over your own practice and improvement, leading collaboration, or setting standards.
Concrete and flexible standards exist for both development teams and drumlines. For development teams, they may exist in the form of coding guidelines, collaboration channels, ticket process, branching strategy, deployment strategy, etc. For drumlines, they may exist in the form of stick heights/dynamic interpretations, technique, marching style, rhythmic interpretation, etc. These guidelines develop naturally and evolve over time, as well as being set in stone from the start. The dissemination, development, and adherence to these guidelines create challenges that lead to growth for participants.
Previously, I wrote a post about why car enthusiasts make good software engineers. So, is my assertion that car enthusiasts and drummers are better software engineers than those who aren't, and am I suggesting that software engineers should go out and buy a wrench and drumsticks? Certainly not. However, I believe that any passion and experience can be leveraged to build upon another, even if seemingly disparate in nature.
Lessons learned in anything can, and likely should, be applied cross-discipline and contribute to your growth as a person. One of the most important lessons I ever learned came from a drum lesson where I was too stressed and sleep deprived to effectively perform. So, what did we do? We sat and talked about drums and life. "We aren't here to get better at drumming - we're here to get better at life, and drumming is the vehicle." And so, whether you're a drummer, a dancer, a car enthusiast, a painter, a chef, an athlete - I challenge you to view these pursuits as vehicles towards the betterment of yourself, your products, and your peers.