We Still Need Coders and Composers

The Philosopher’s Stones are a legendary substance used by alchemists to turn anything into gold. They are also what Philosophie, the product design and development consultancy that I work at, refer to as their core values. These values make sure software engineers like me are able to work with clients and team members to “turn ideas into gold.”

Overture

A while ago I read an article on Medium that made me feel a variety of emotions: the first one being anger. As a software developer, just the title alone was enough to trigger an existential crisis. The article I am referring to is Coding is Over by Lauren Mendoza. If you haven’t read it, go check it out. Basically the gist is, software engineering is not really “engineering” because they’re solving the same problem over and over again by writing more CRUD apps and that the people in this profession tend to be overpaid egotists. The author goes on to say that we should’ve figured out how to automate most of what software engineers do by now. Initially reading this upset me because hey, I’m one of those guys she’s slamming. But the more I thought about the article, the more I felt fear. What if she was right? The article has many comments in support of her piece, so clearly she hit on something that’s on a lot of people’s minds. Is what I’m doing now, writing code and building apps, all pointless? Am I going to be replaced by a robot in the near future? What was the point of me spending hours writing code and paying for an expensive undergrad degree in computer science if, in the end, a robot is going to do it better than I can?

Coding Is Over (kind of)

I spent quite a bit of time reevaluating my job title which I am quite proud of: software engineer. It’s a job I have wanted since taking my first computer science class in college. Discovering that I could build things with a few keystrokes was a game changer. I had always enjoyed helping my grandpa make birdhouses and furniture in his wood shop, but that was a lot of work. Buying the wood, sawing it into pieces, sanding it, nailing it together, staining it; there’s a lot of labour that goes into it. But coding, all your tools are on your laptop and programs come to life from the poetry that you write. It’s like magic.

Taking computer science courses like algorithms and data structures was fun and all, but for me it was not fulfilling. Computer science to me was a means to an end. I didn’t want to be a computer scientist, I wanted to be a software engineer. I wanted to build things and see people use my creations. Reminding myself of why I had initially decided to go into software is what helped me realize why I am not obsolete. The truth is, Lauren Mendoza is right. There are a lot of apps out there that are basically the same. Robots don’t make petty mistakes like writing typos. But my argument is that it doesn’t mean coding is over. I’ll explain my realization further using the help of my other passion: music.

A QUICK ANALOGY TO MUSIC

It’s not a reach to compare writing code to writing music. They both require a person to mark instructions down, which then get interpreted and executed by other entities (CPU, orchestra, same thing). So I will pose the same question the article asked about coding, but this time for composers: why are people still writing music? Haven’t we figured out how to write songs? There are formulas for writing pop songs, R&B songs, and rap hooks. There are templates for writing fugues, sonatas, and cantatas. We know which chord progressions will make a car chase scene exhilarating, and which ones would make us emotional during a dramatic scene. So why do people still write songs? Why do people like Hans Zimmer get a fat paycheck when we as a society have literally been writing music for centuries, and now have the technology to have it automated? There is software that can output pieces in the style of Mozart, or Haydn, or whoever else. Based on parameters set by the developer, the software is able to mimic a style of a composer. It’s also not a far out idea to have a machine produce a few chord progressions given an adjective. The term “sad” would produce a piece with minor chords, “anxious” would use dissonant chords, and “regret” would give you a Nickelback album. So the question remains: why do composers still have a job?

It’s because there are a few things that composers can do well that robots cannot (not yet, anyway). Coincidentally (probably not a coincidence), these few things are also why software engineers have a job and will continue to have a job. These important factors that ensure software engineers and composers keep getting paid are nicely summed up in the core values at Philosophie, where I work and learn. The founders of the company decided to call these things the Philosopher’s Stones, because they’re able to turn lead into gold like in the legend. The five Philosopher’s stones are: Same Team, People Before Pixels, Less but Better, Shipit, and Make It Better.

Same Team

I’ve never had a job as a film composer, but if I had, I imagine it’d be rare to have complete creative freedom over the soundtrack for a film. I highly doubt there’d ever be a film where I just send the mp3 file to the director, and the director would just plug those into the film without asking any questions. They probably have to work quite closely with the director and the production company. The same thing goes for developers.

I’m not sure where the stereotype of software developers being solitary creatures comes from, but it could not be farther from the truth in my experience. From the designer to the client, as a software developer I am required to work with everyone who has a hand in the project. For the project to run smoothly, I need to be able to interface with the different roles of the project and communicate effectively. Some days it feels like I spend half of my time coding, and the other half talking to people in person or online. This is a wonderful thing. It affords me countless opportunities to learn about my teammates and adapt how I work to be more in sync with them and to deliver more value faster.

Same Team is all about breaking down barriers that might arise when working on a project with a group of people. Some common barriers are: us vs. client, devs vs designers, devs vs. devs in another department, etc. Communication suffers when these barriers are erected, thereby threatening the health of the project. When communication becomes harder and people’s intentions become opaque, all sorts of things go wrong. Promises are made that are bound to be broken and people will be disappointed. Knowledge isn’t transferred throughout the team and the same work is duplicated. Unlike robots, as developers we have the ability to empathize with our fellow teammates in order to avoid the pitfalls mentioned above. We can help PM’s understand the technical complexity and challenges of a given task in order to plan out the sprint. We can include the client in discussions about the different solutions for a desired feature so they know what you’re spending your time doing, and what they’re paying for. Communication should be a top priority as we go about our work day.

People Before Pixels

If you’ve ever listened to twelve-tone music, you’ll understand the principle of People Before Pixels. Twelve-tone is a technique developed by Arnold Schoenberg that was popularized in the 20th century, and was revered in academic circles. There are really cool music theory things happening in pieces of this style, but they usually sound like a cat walking on a keyboard. Reading about the ideas behind twelve-tone music is fascinating, but does anyone actually enjoy listening to it? There’s a reason why you very rarely hear the late works of Schoenberg on the classical music station on the radio.

You could build an app that’s very sophisticated and uses all the tools that you’ve wanted to play around with, but if you never talked to users while building it, no one is going to use it.

When I say People Before Pixels, I’m not only referring to the people using the product but also to people making the product. There’s rapid change all of the time in our field and shiny new toys emerging on a weekly basis for developers to play with. How many of you who are web developers have googled: “which frontend framework should I use? <insert year here>”. When there’s a new frontend framework coming out every other week, not only is it difficult to choose which one to use but there’s a natural compulsion to use the newest, hottest thing out there. Software developers aren’t the only ones guilty of flocking to new technology like moths to a lightbulb. It’s not uncommon for clients to want their project to be built with <insert whatever’s the hotness this year>, because they read an article about it on Medium and everyone’s talking about it. We need to take a step back and ask ourselves which tool is best for the job without jumping to the coolest one on the market right now. Maybe it doesn’t have to have a frontend framework; maybe it could just be a normal Ruby on Rails app. Or maybe you just start with an HTML page with some jQuery to test the idea first. When choosing a tech stack, we should think about those who are working on it now and those who will be supporting it in the future, and make sure they aren’t miserable.

Keeping People Before Pixels in mind is all about choosing what’s best for people, whether that be the enduser or the people working on it. The right decision is the one that makes users and developers feel happy and excited about the project.

Less, but Better

Does anyone rock out to elevator music? A crazy person might. Why does the average person not have a playlist of elevator music that they jam out to? It’s probably because it sounds like it could’ve been written by a robot. Elevator music is designed to appeal to (or at least not offend) anyone who might walk into an elevator, which could be a lot of different people. It’s purpose is to pander to as wide an audience as possible. It serves it’s purpose, but that’s also why no one particularly enjoys it. The tracks that people come to love and adore are those written by actual talented musicians. Sure, not everyone is infatuated with John Mayer like I am, but that’s ok.

There are lots of products out there that try to do too many things for too many people. These types of products tend to have a poor user experience because it didn’t have you in mind; it had dozens of types of people in mind. Success comes from being focused on solving a very specific problem, for a specific type of person. There are, of course, products like Facebook that have mass appeal. But even Facebook started out with only college students having access to it, and eventually grew from there.

My point is, it’s generally hard to solve a focused problem using generic tools. If you want to solve a specific problem that no one has solved before (or hasn’t solved well), chances are you’re going to need to buckle down and roll out your own code. For example, maybe there’s library that has one method that you want to use. The thing is, this library is huge. And not only do you have to include this library, but you have to write code around it to force it to do the thing you want it to do in the way you want it. That library is huge because it’s trying to do too many things. Even if this library provides some things out of the box, perhaps a better solution is to roll out your own implementation that does what you want, and does it better?

Make it Better

You know that feeling when you’re on the billionth revision of an essay, and you still aren’t sure if it’s the last one? I hear artists talk about the same feeling when they’re working. They’ve spent hours on one piece, but still aren’t satisfied. Building software should feel the same. There’s never a time where we stop working on a product as long as it has users. Supporting the product and fixing bugs, making optimizations and paying off code debt, introducing new features, conducting user tests to see what can be improved, the list goes on for all of the things that need to keep happening on a product after the initial release.

The Make it Better Philosopher’s stone is exactly what it sounds like. Improvements should be made whenever anyone notices an opportunity to make one. Coding can be seen as a craft, and as craftspeople we should never stop trying to improve our handiwork. There are infinite chances to refactor a code base. The other week a couple of developers and I decided to take time to do some refactoring because we were ahead of schedule. The more we extracted methods and classes, and the more we shifted responsibilities to where they made sense, the more we realized we could spend weeks just refactoring and not delivering new features. There’s never a piece of code that should be left alone for the life of a product, and someone needs to be around to continuously make it better and support it.

Shipit

So I just talked about making things better, and always striving for improvement and yada yada. But this is real life. We could spend weeks refactoring, but that doesn’t mean we should. There are deadlines to be met. You could have squeaky clean code but at the end of the day it doesn’t mean a thing unless you’ve shipped it.

The Philosopher’s stones are centered around empathizing with the people using the product, but how do you know what these users like and don’t like? You have to Shipit! Make small incremental changes and put it out into the world, and see how it does. Got a cool idea for a new feature? Hack it together and shipit. Want some data to back up an amazing idea you have? Roll out a prototype and shipit. Whether you use some sort of prototyping tool or code something together is up to you. The important part is that you’re able to quickly put something together and put it to the test.

The best way I can compare this to music is how Jazz musicians perfect their style. Improvising and trying out new material, seeing how the band grooves to it or the audience reacts to it and learning from the experience. I admire artists who aren’t afraid to try new mediums or styles, and learn how to do something new with old influences. We should strive to do the same when we write software.

Fin

Alright so maybe I took the analogy too far. But nonetheless I still believe composers and software engineers are not so different. We are in highly creative professions, we strive to create things for others and ourselves to enjoy, and we enjoy learning about and putting into place complex systems (take a semester course in advanced music theory and you’ll know what I mean). As long as people want to hear new music, composers will write notes. As long as there are problems that technology can solve, software engineers will write code.