Making music is not like making software

… or “How I made an album and learnt something about software development”.

Editor’s Note: This is a blog post by Michael Tokar, one of our Engineering Managers on JIRA. He is pretty awesome at making music, and developing software.

Before we begin…

Below is the album that I’m talking about making, in its finally-released-and-fully-realised glory. Why not press play and listen to the thing I’m about to talk about?

As a software engineer, it’s not uncommon for me to try to apply engineering principles to non-software engineering problems. “How can I optimise the workflow of taking out the garbage?” or “What route should I walk my dog along that will not see us retrace our steps?”. These are some of the everyday challenges I think about outside of work.

Anecdotally, it seems that there are a lot of musicians in the field of software engineering. For me, the link between musician and engineer is not accidental: I embrace the analytical mindset in my creative outlets. I find that it helps me to think about music composition in terms of patterns and sequences. I love playing stuff in strange time signatures, and I also love playing straight-up grooves. But I don’t think the reverse is true: I don’t think there are a lot of software engineers in the field of professional musicians, or in the music industry in general. At least, that has been my experience so far. Certainly, no one else in my band works in this space.

So when my band and I set out to write and record our latest album, I got my engineer’s hat on. A creative and collaborative project, spanning months to years of effort, to produce a product for customers and with the help of external stakeholders. At the surface, you can see how easily enticed I was to approach this like I do in my usual professional way. But as I have learnt during the past 18 months, these surface similarities don’t run deep. And so, because I’ve often been asked by fellow engineers “What’s actually involved in making an album?”, I thought I’d recount some of the striking similarities and differences I found between making music and making software.

Musicians’ attire is not the same as engineers’ attire

On Technology

It’s no secret that technology, especially software, plays a massive role in the creation of music today. I’m sure everyone’s heard at least one story like this: “Child prodigy creates smash hit in his bedroom using Garageband”. Indeed, the entry cost for creating music is rock bottom: the market is flooded with hardware and software that can sound professional enough and cost less than your actual instruments did when you first learnt how to play guitar. My band and I used a host of different software to take us from “concept to launch”. Here’s just a few of the key tools:

Dropbox — absolutely essential for sharing ideas between band members. We’d often record jam sessions in our rehearsal space (on an iPhone!) and then someone would have the task of uploading it to Dropbox so everyone could study it. Incidentally, one of the features that I found sorely lacking, up until just recently, was the ability to comment on files in Dropbox.

Ableton Live / REAPER — these two programs are the main DAWs (Digital Audio Workstations) that we used to compose our demos, with REAPER being the DAW that our producer used for his engineering and mixing workflow for the actual album. I mention both here because they’re almost two opposite tools.

Ableton Live is developed by a company in Germany, who’ve done a lot of work on building their brand and reputation as makers of very easy-to-use tools, that can still do powerful things. Incidentally, you can see on YouTube how they run their own engineering outfits (their “agile” story reads a lot like Atlassian’s).

REAPER is made by Cockos Incorporated, a U.S. company who were “founded in 2004, beginning an effort to build quality software that would benefit people throughout the world” (sounds very familiar to Atlassian’s mission: “Advancing humanity through the power of software”). It’s not only their mission statement that is familiar. REAPER is like “old” (pre 6.0) JIRA — completely customisable to a fault. Using it, you can simultaneously feel utterly powerful and lost. REAPER is shareware, interestingly, which makes it a compelling choice for the frugal and a real disruptor for some of the more established players (Cubase and ProTools, amongst others).

Google Docs — “What kind of rockstar uses spreadsheets?!” is what you’re probably asking yourself right now. Truth of the matter is, we have a distributed team: the three band members all live in different parts of Sydney, and our producer lives in Canberra! We all work day jobs, so we needed a way of collaborating asynchronously. I honestly have about 5 times as many Google documents in my band account than I do in my personal and work accounts combined. Everything from track compositions, to mixing notes, to touring budgets can be found amongst our collection of documents.

Asana — It’s true. I’m catfooding Asana for managing the project that is launching our album. Before I introduced Asana into the process, we were using Facebook Messenger to communicate tasks and status (not fun). You’re probably thinking “Why not JIRA?”. After 8 years of working on JIRA, I know what it is capable of. I can configure it in my sleep. But I’ve never had the opportunity to genuinely use a competitor product in a realistic, sustained scenario, where something real was at stake. To be honest, the decision to bring in a task management tool was a very late one. In the lead up to the album launch, there are so many things happening all at once, with multiple tasks being added and resolved daily (and that’s just between two people). The tasks are very scrappy in nature: “Did you remember to do this?” or “What do you think about reaching out to this person?”. And so knowing what I knew about Asana (versus Trello, for example), I thought it would be a good fit.

With all of the above software choices, the thing that binds them is that they’re all “lowest common denominator” choices, in that we could only all use what the least-invested person was willing to learn (and some of the people I needed to “teach” I have considerably less influence over than others). I often forget that I work in a pretty niche field — making tools for software development and collaboration — and that not everyone else I ever collaborate with will instantly understand the workflow of a new tool (no matter how friendly their onboarding flow is).

So this process has been a pretty loud reminder to me that most of the Atlassian customers of today, and especially the Atlassian customers of tomorrow, will not be experts in our tools, and they probably won’t be using our tools by choice. Our job is to convert them into promoters by helping them understand why they’re using a tool to do this job that they were quite happy doing manually (or inefficiently) for the past 5 years.

On collaboration

When you work with intelligent, passionate people day-in day-out, it’s easy to forget that you don’t always get to enjoy “optimal working conditions” in other life endeavours. This is by no means me having a whinge about my bandmates. Far from it: collectively we’ve worked pretty damned hard to make this happen. But when you take away all of the creative problem solving that is writing music in a band, what you’re really left with is people problem solving, and there’s only so much technology or an engineering mindset can help you with that.

The limiting factor is definitely “face time”. In the band, all of us have day jobs. The people we work with outside of the creative process — the label, the manager, the booking agent, the publicist — they all have day jobs (not necessarily the one we are employing them to do). That puts a very hard limit on the amount of hours you have in the day to work on some of these people-centric problems.

Sometimes, issues came up where clear and timely communication was needed, but time wasn’t available. I thought it would be simple enough to switch to asynchronous communication, without losing the urgency or intent of the message. Turns out this is really hard. I found myself leaning on my trusty tools to help me through. There’s a natural order to them in terms of suitability, like a “totem pole of communication”.

1. Asana is my best hope, as it affords clear action, transparency and a paper trail.
2. Google Docs are good; at least it’s still highly collaborative, even if the actions aren’t always clear.
3. Email is getting bad, particularly when you have multiple people managing one inbox.
4. When you’ve resorted to texting someone, you know you’ve thrown good intention out the window and are just desperate to make something work.

But here’s the challenge: the lower you go down the totem, the higher the potential for misunderstandings. The higher you go up the totem, the more invested you need everyone to be in making the communication work. This is almost a given in a professional software engineering context: you’re literally on the same team. But that doesn’t automatically make it effortless to establish these communication practises and team processes.

People problem solving becomes hard when asynchronous communication is not working well, and synchronous communication is hard to organise. Again, this shouldn’t come as a surprise to anyone, but it was another take-away for me that while at work, we should take advantage of our hyper-connectedness, and move to solve people problems in the most gratifying and efficient way possible. Don’t let a conversation drown at the bottom of the totem pole.

Closing thoughts

I love that I get to solve problems every day, whether they be engineering, creative, logistic or people problems. I’ve been privileged to have enough time and energy to pursue creative endeavours outside of work, and I partially owe that to Atlassian for providing me with a great working environment. Thanks to everyone — engineers and otherwise — who listens to me talk about music stuff incessantly. And if you’re still listening to the album stream above, you’re pretty great!