Drumming up code for <SaaS/>

Graduating from music school 6 years ago in good ol’ Montréal, I couldn’t have guessed it might be the start of a career in making things for the web.

The writing on the wall didn’t read anything like:

“Your music education is hereby complete! Go forth and earn a healthy paycheque, performing for millions as grand-master percussionist of the world!”

Haha. Nope.

But when I landed my first gig doing web & graphics, the half of my life I’d spent training a musical skill started to creep its way back in. Sometimes in the way you’d expect, sometimes not.

Here’s a few of them, from a drummer’s perspective.

Reading your own gobbledygook

Among the most interesting things that coders and musicians share are the languages and patterns we use to communicate.

With sheet music, it’s pretty clear that we’re writing for other musicians. Besides all the dots peppered around the page, we’ve got Latin & English phrases as clues.

Just take a look at this beautiful monstrosity:

Not much hope we’ll be headlining the Death Waltz at Coachella this year, but I hope you gave it a shot. :)

The point here is that while your app’s code like Javascript, Python, or HTML is run by a computer, it’s still destined to be read by humans. Even if that person is future-you, there’s no guarantee you’ll remember what was rattling around at the time.

Good quality code tends to speak for itself, but I firmly believe that thoughtful naming conventions and internal comments/notes make a big impact on its future. Apply that extra 10% love for your future coding human.

I’m not just talking to coders here. Documenting the small decisions & assumptions you make while building an application and/or a base of users is essential. When you add a feature, or pivot an existing one, these little things float to the surface — costing additional time & money.

In short: bring your pencil to rehearsal, or risk getting kicked out of the next one.

Red - Green - Refactor

This one’s quite a popular pattern in programming, and flexible to pretty much any profession I can think of. It lends itself to concepts like “iterative design” and “test-driven development”, but I’m more interested in failure.

In a programmer’s world, understanding failure is often more important than success. For every 1 feature, there’s 1o1 ways to break it. Running a big base of users through your code is like opening the floodgates to a stream of water… all the cracks are uncovered eventually.

Not an ideal testing strategy, eh?

Plugging cracks like these ahead of time requires forcing all kinds of failure, and starting a healthy relationship with it. Invite it over for tea, ask politely about its friends, family and when it’s leaving for vacation (hopefully a 1-way ticket).

Learning a piece of music requires much of the same patience and understanding of failure. We break big problems down into smaller parts, and work to bring them into the green. When the pieces work, but don’t fit together, it might be time to refactor and try again.

So what might Red - Green - Refactor look like for a musician?

1. Red.
   Fail and fail again. Exhaust your list of solutions, and imagine up a few crazier ones. Learn what you can along the way. #thestruggle
2. Green.
   Hurrah, you played the notes on the page and it ‘technically’ works. Sure it was just once, under stable conditions, but enjoy that endorphin rush!
3. Refactor.
   It’s time to build consistency, and turn those raw motions into sweet music that incites emotion. Either you’re polishing out cracks, or adjusting your definition of success. Just be ready to loop back to Red.

Failure can be your best frien-emy (friend/enemy), who’s plotting long-term to destroy take down what you’ve built. Play devil’s advocate now, so your application can fail elegantly when it does hit the fan.

Small ensembles: great power, greater responsibility

Rehearsing with an 80+ piece symphony orchestra is real exciting stuff. Each musical section, made up of different interweaving parts, moving together as one. It’s a quite the sight.

And there’s me standing at the back, waiting for eye contact from the conductor.

We’re nearly there…. yes, Andrew…. your big moment!

…… ding.

Big orchestras, like giant tech companies, accomplish some huge feats with music. Ding. But they don’t have the same monopoly over concert halls and music festivals like they used to. Since the 50’s/60’s, we’ve watched groups small as 3 or 4 plug in and bringing a grand concert hall to its knees.

Rock’n’roll baby!

My high school band “The Blues Channel” in 2006, my afro in full bloom

In today’s lean startup world, a small team of 3 or 4 can have the same effect. These whippersnappers plug in their guitars, fire up amplifiers, and dial that shit up to 11. Sure, the giant orchestra may never die, but it gets quieter every year.

Working in a small ensemble means spreading out the responsibility, and becoming extra sensitive to others’ ways of solving problems.

Because despite whoever’s in charge (if anyone), the baton gets passed around frequently. When it’s your turn, keep in mind that it’s a whole musical section you represent, not just a ‘Ding’ in the background.

So, should we just hire musicians then?

I’m tempted to just say yes. The end!

I attended the Bitmaker Labs (9w developer bootcamp) in Toronto, and quickly discovered that students’ strongest assets to coding were actually previous work experience and education. Rather than ditching it at the bottom of our resumés, we were encouraged to let it inspire interesting apps that solved unique problems, on which we were subject matter experts.

We certainly weren’t experts in coding or app design. Students joined the program leaving behind careers in finance, healthcare, industrial design, and more. The ones who really succeeded found ways to marry their past with a future in code.

For example, I made a sheet music writer app for drummers, and now find myself in my second startup working with notes/documents. It wasn’t an intentional decision, but not exactly an accident either.

If you’re hiring for a new position, really take the time to look at the applicant’s past education and work experience. Pick at it with some easy questions, and give the applicant a chance to open up that part of their life. When the passion & tenacity taps start to flow, just sit back and listen — it’s a wonderful ride, and full of value that your startup can draw from.

And if you’re sitting on the other end of that table (like I recently was)… Frank Zappa wants you to bring the eyebrows.