Dear Future Colleague,
My heart has always pulled me in seemingly opposite directions. I guess it could have something to do with the genes. My dad was a university engineer who then went into insurance and later founded his own business. Meanwhile, my mom was a professional dancer who now runs her own dance school. My artistic side struck early — I started playing piano when I was just five years old. But at the same time, I loved mathematics in school. That dichotomy carried on during my service in the Finnish military. I was an AA gunsmith (definitely more engineering-focused), but then during my last three months, I played in Conscript Band.
You might think with such disparate interests it would be hard to find a career path to suit me. But it wasn’t. I’ve got the perfect balance in my job as a software developer. In fact, many lessons I learned as a musician I now apply as a coder.
Listen. Then listen some more.
When you hear a song for the first time, or maybe several times, you’re really just picking up the melody. Even the most analytical musicians aren’t listening to individual notes at that point. But over time, you start to hear nuances. And you’re able to separate the melody — what carries the song through — from the beats and measures that give it life. You may even pinpoint some aspects that you would change.
It’s similar with software development. When you first get handed a project, it’s important to spend some time with it to get the overall picture. First of all, recognize what are the bones of this software, and what sets it apart. And then as you dig deep into it, start to focus in on any problems that exist and how they might be solved, as well as some areas that could benefit from a tweak.
There’s more than one way to do things
The beauty of music is there are so many paths to get to the same destination. Do you want to write a song that sounds sad? The first thought is to use a minor key. That’s the tried-and-true method. But you might be able to evoke the same emotion by slowing down the tempo or using a particular instrument (cello, anyone?). The point is there’s no “right” way.
That’s the same with coding. You can get a team of developers together, give them all the same ticket, and each of them could come up with a different solution. I like that the job allows for that individualism. Many people think programming is very black and white — it either works or it doesn’t. But in reality, there’s a lot of room for variation within the “it works” designation. This part of coding feeds my creative hunger.
Failure is okay
At my first piano lesson, I wasn’t given a music sheet and told what C major was. Instead, I learned the Suzuki method, which is playing by ear, and I quickly learned that it’s a game of trial and error. Honestly, you might just sit down to play, plunk out some notes and as soon as you do, say in your head (or sometimes out loud), “no,” then try again. And that pattern repeats and repeats until you’ve figured it out. Of course, that’s fine when you’re practicing — that’s the process. And when you’re composing or jamming, there really are no wrong notes, just infinite possibilities. But it’s way different when you’re performing Fur Elise on stage. The audience knows the song and can anticipate what’s coming. If you deviate from it, they’ll notice.
The same holds true in software development. If your software already has users, they have expectations and you can’t just break the software or do drastic changes to the production version. On the other hand, when developing new features, you’re encouraged to experiment and try out different things. Some of them will work, and some of them won’t. But getting comfortable with failure is a really important step for a programmer.
Don’t limit yourself
Do you know people who are staunchly into punk, country, or classical? While I’m all for having a preferred genre (movie soundtracks for me, please), it can be really limiting to listen to only that. Paul McCartney said one of his favorite songs is Fred Astaire’s “Cheek to Cheek.” For a frontman of one of the most famous rock bands to be inspired by a singer/dancer of the 1930s and 40s, well, that says what reaching out can do. There’s a ton of great music out there, and I think there’s so much you can learn from exploring different types of music, especially if you’re a composer.
Variety is one of the great elements of consulting work. You have the opportunity to work with many projects, with a lot of clients, among different industries. The more you can take in from all those different experiences, the better developer you’ll be. And you can take learnings from one project and bring them into your next — just like I’m sure Paul brought “Cheek to Cheek” into “Eleanor Rigby.” 😉
Get something on paper
There are some musicians who tinker around with pieces for months, even years. They don’t want to release it to the world until it’s perfect. Many classical composers, such as Beethoven, wouldn’t even commit their symphonies to paper before they’d figured it out completely in their head. The problem with that is you can get really analytical and second guess every movement — or even note. It may even paralyze you from finishing it at all.
Some developers fall into this trap, stretching out the research phase and holding out on any sort of release for far too long. I’m not suggesting that research isn’t important and you should jump in right away without the data you need, but proof of concepts and prototypes move things forward. From there, you can iterate based on actualfeedback, instead of relying on your own thoughts and misgivings. This is the agile way, and it’s very effective.
Jazz isn’t just improv. It’s teamwork.
There’s a big difference between a symphony played by a philharmonic orchestra and a jam session that’s put on by a jazz trio. The orchestra is performing a piece they have rehearsed dozens, perhaps hundreds of times. Every note is clearly identified for each musician and the success lies in each individual carrying out exactly what is on the page according to how they’ve always done it. The jazz trio has none of that. They are improvising — creating music as they go. Just like with the orchestra, their success is rooted in their collaboration. But with them, the crucial parts lie in knowing each other’s strengths and weaknesses and being willing to support each other by being reactive.
Software development is much like the jazz trio, especially on agile teams. Assembling a balanced team is what lets the project stay afloat — it’s kind of what carries the melody. However, at certain times in the project, a specific person can shine. That’s where knowing the different members’ expertise can prove really helpful. There’s also room for others to try their hand with different or new tools, languages, technologies, etc. — sort of like a riff — and see what can evolve from that. It’s a lot of give and take, but that’s what many times leads to the best product.
Make it accessible & inclusive
Back in the 1800s, basically the only people who heard Mozart were those who could afford a seat at the opera or were friends of the royal court. But today, as long as you’re willing to shell out a little money or listen to ads on Spotify, you can be exposed to an incredible amount of music from all sorts of genres. No matter who you are, you can find something that appeals to you.
We aren’t quite there yet, but that’s what I want for software development, too. There’s a real need — and opportunity — to make digital products for everyone. The internet has opened the door so that a lot more people can access the things we as developers create. But it’s important that we make sure they can be used by and appeal to as many as possible.
Use it as a way to bring people together
If you’ve seen Top Gun you probably remember the scene where Goose sits down at the piano and everyone in the bar comes together to sing “Great Balls of Fire.” (Incidentally, the scene was replicated in the sequel, Maverick.) Well, I had my own version of that. When I joined Reaktor, one of my first nights we went to a club in Amsterdam. I still didn’t really know anyone, but I saw a piano and started playing. All of a sudden, the team came around me and joined in singing. It was an unexpected but really natural way for us to bond. But that’s what music does to people. It’s been called a universal language, because it can be understood, felt, and loved by everyone.
During Covid, we saw how software like Zoom could allow us to be together, even when we’re apart. Unfortunately, technology also has a dark side, where it isolates people (many studies on social media have looked at this) or creates divisions. I think as developers we have a responsibility to create products for the good of society, which starts with being more mindful about the effect our work can have.
Sometimes I still think about maybe pursuing a music career in the future. But for now, I’m happy that I’m able to take my love of music and the things I’ve learned from it to become a better developer. See you at the keyboard — musical or computer!
p.s. Want to hear some of my music? Feel free to check out my SoundCloud!
