Programmers and Musicians

April 2019

My last post was a mental dump related to creating a work/education organization with a specific culture. This is a more focused, clarified version of that post.

Programmers don’t get enough time to practice. We should be more like musicians. I’m a clarinetist, and I think we can make some useful analogies. Becoming a great musician involves at least four areas:

(Rehearsing is practicing a specific piece meant for later public performance, whether individually or as a group. By practicing, I mean practicing things like scales, articulation, intonation, etc.)

Great programmers need to spend time in four similar areas:

Individually, we know the value of practicing (employers know that it signals “passion”–a rant for another time). However, our institutions don’t reflect that knowledge. Imagine trying to get a degree in music performance if you only practiced scales ad-hoc–whenever you had a lull in your other obligations. And yet that’s what happens to computer science majors. Instead of practicing, you spend too much time on rehearsing and theory. Anyone involved with interviewing recent CS grads knows the result.

It’s a little better after graduation. If you get a nine-to-five, at least your evenings and weekends are a bit more protected. Maybe you even have an enlightened employer that gives you 20% time (“Good news, musicians–we’re now going to let you practice scales every Friday!“).

Why is it like this? I think it’s because if musicians stop practicing, you notice more quickly. If I went to an orchestra rehearsal after a week of not practicing, my fingers would feel sluggish and my lips would hurt. Practicing as a musician is possibly as much about retaining your current skill as it is about improving. But in programming, your skills don’t regress so quickly: practicing is more about just improving your skills. So when we don’t practice, we don’t feel an immediate, negative reward. We just miss out on the better skills we could’ve had.

My argument is simple: programmers would have higher output over the long run if they could spend more time on their own projects, learning autonomously.[1] Here’s my plan to test this hypothesis:

  1. Create this lifestyle for myself as a consultant. I prefer to work on one thing at a time, so the best situation would probably be working on a contract for N weeks and then spending the next M weeks working on a personal project.

  2. As I build my own consulting business, hire other programmers and create a culture that supports this lifestyle.

  3. As the organization scales, there will likely be some personal projects that could grow organically into good products. We’d gradually switch work from consulting over to working on these products, since selling our own software can have higher gains than renting out our time.

I’m just getting started as a consultant myself. From my limited reading, it seems that with some work you can expect to make much more than you would as an employee–that’s good because it’ll make it easier to support myself without spending all my time working for money. However, I’ve also read that creating a profitable non-solo consulting business is really hard. Now it’s a distributed system instead of a single entity, and you have to deal with the associated overhead.

I’m hoping I can overcome this challenge like so:

There are more implications, but that’s the plan. Wish me luck.

Russian translation


[1] I also think that colleges teach the wrong kind of theory, but I’ve written about that elsewhere.

Got feedback?