In an email this week, Greg Wilson asked me why music playing was centred around individual tutoring but programming education was not, i.e., why professional musicians still take lessons but professional programmers do not. That reminded me of this article I’d recently read about Fender ( in this BBC article and this [paywalled] FT article). I wondered about similarities and differences between learning music and learning programming — especially end-user programming where people do small bits of coding in larger systems, like formulas in spreadsheets, scripting in image editors and so on.
Gender Balance, and Goals
Like just about every other industry on the planet, guitar manufacturers have generally neglected the female demand for their product. Turns out half of all guitar buyers are women, and half of those buy electric (unlike the stereotype of women playing acoustic). It also turned out that many purchasers didn’t want to become performers — they just wanted to play by themselves. In his SIGCSE keynote, Mark Guzdial mentioned how many more end-user programmers there are than professional programmers, yet the former are treated like a pale imitation of the latter.
Drop-out Rates
You may think computing courses have high drop-out rates, but Fender discovered that within a year, 90% of purchasers have stopped trying to play, and many of those stopped within the first three months. In Fender’s case they have a clear economic motivation to fix this — if no-one can learn guitar they are not going to buy another (and they’re going to ebay the one they did buy). So Fender were driven to aid learning by making apps and tutorials. In this, perhaps, computing is not so bad — there is a wealth of material out there for learning to program.
One difference between music and programming is that we can change what programming looks like. We can’t change the core programming concepts but we have the ability to make our tools more helpful and less painful. However, the guitar is inherently unmodifiable. Sure, we can allow guitar music creation using simpler tools — keyboards and MPCs and computerised music generation — but that’s not a guitar.
The invention of those other tools did lead to an explosion in music creation though. A bunch of UK dance and electronica bands in the 90s got started by messing around with electronics and computers and seeing what came out, and similar patterns led to the rise in hip-hop producers in the US at the same time. The tools did make a difference in who could make music and how easily.
Reality Bites
My uncle said about his efforts to learn the guitar: “I pick it up for a few hours and I can make noise, but then I get frustrated that I’m not playing like Eric Clapton and put it down again.” We have expectations about what we can achieve and we all want a quick win rather than a long painful process. The programming equivalent is perhaps the young kids who want to make the next Call of Duty but then find they’re struggling to draw a turtle graphics hexagon on screen. Again, programming can build helper libraries and layers of abstraction to make this process much easier, more so than music playing where reality bites: when you pick up a violin for the first time, nothing is going to stop your ears bleeding as you try to hit a note. The musical alternative is to use an easier instrument, but in music and programming, such beginner’s tools are often sneered at.
Lessons
Music teaching is a mixture of formal and informal. Some learn in schools, some have one-to-one tuition, some learn for themselves via the Internet. There is a temptation among those who learned programming by themselves to describe formal school teaching as unnecessary — why doesn’t everyone do what I did and teach themselves? But just because some learn themselves doesn’t mean that others wouldn’t benefit from widely available teaching. I learned programming by myself with a handful of books for years before I took any programming classes. But what I now wonder is: how much faster could I have learned with a teacher? Just because you can learn a certain way doesn’t mean it’s best.
This is a good excuse to trot an anecdote about Jamie Smith, the producer member of the British band The xx:
[Smith] was already being hailed as a visionary figure by his label boss at XL Recordings, Richard Russell. “I found him really inspiring as a beatmaker in quite a specific way,” says Russell. “He was playing the MPC – which is a piece of studio equipment you’re supposed to use for recording and sequencing – as an instrument. That idea sort of blew my mind: that you could play something live and still have the sounds I love, the sample sounds. I started doing it myself straight away, on Bobby Womack’s album, on the stuff I was doing with Damon Albarn.” (“I didn’t realise you weren’t supposed to do that with it,” shrugs Smith. “I still don’t know how to use one properly.”)
Feedback
You might say there’s three types of feedback in learning. One is the obvious signs of success — does the code compile? Does the guitar make the right note? Another is longer-term pain points — is the code hard to make changes to (e.g. because of lots of repeated code)? Is it hard to play the notes at the right pace? The third is higher-level features that aren’t obvious without external feedback — is your code well structured for others to understand? Are you using an interesting variety of musical techniques?
The lack of useful feedback for the second and third items often crop up in end-user programs. You find replicated chunks of near-identical code because the programmers don’t know about functions, repeated variables like x1, x2, x3 because they don’t know arrays and so on. It’s an unknown unknown — how do you get people to write better code when they don’t know what better is, and don’t know what techniques are available for doing so?
Summary
Learning has similar challenges in programming, music and other domains. There is a diverse set of ways to learn: self-taught, tutored, formally taught in classrooms, informally taught by peers, and so on. If we focus too much on one and assume it fits everyone, we can miss out on a lot of potential learners. What I’m struck by when observing some of our Blackbox participants is that programming can be a slow, frustrating and painful experience for many who are by themselves. There is no-one solution to improving learning: it needs to be a combination of language design, tool design, pedagogy, materials and more.
Academic Computing 
Great article! As someone who teaches coding AND also plays guitar, I found the parallels fascinating. I learned the guitar by trying to learn songs I liked. So that’s kind of like trying to make certain effects happen with your code. I was way too impatient to sit through guitar lessons, and many beginning coders are probably like that, too. As you say, there is no “one size fits all”. Everyone learns differently. My experience with teaching middle school is that most students want “just-in-time” learning.
Could the difference in teaching methods for guitar and programming be related to the procedural knowledge vs. declarative knowledge split?
Learning to play an instrument relies heavily on procedural knowledge: you rehearse motor pathways until they become automatic. Much of what is happening is happening below awareness and cannot be verbalized. Here it is much easier for a teacher to watch and show than to translate the subject into language. Unfortunately, that does not scale well.
In contrast, programming is largely declarative. You make conscious decisions about things that can be verbalized. Training is more a matter of absorbing an explicit set of information and then learning how to apply that information. Since the information _can_ be verbalized, and since errors will be less personalized, we can attempt to teach the subject to a group.
Interesting thoughts. Learning music, learning another language, and learning computer science all have a lot in common!
I feel in my own life one significant difference between learning computer science and learning music. Our music education tends to pivot around mimicking other people’s compositions. We learn to play pieces from a canon of established works. Occasionally we improvise during a performance, but only in certain genres. Playing an instrument and composing music are often distinct careers.
In computer science, we emphasize both “playing” the computer and “composing” new software. We may reverse engineer others’ software, especially at first, but very soon we build things that didn’t exist before.