> programming is closer to composing than performing.

This dependents on individual viewpoint though. Salvador Dalí said (paraphrased be me) expert artists are just good at hiding where they stole an idea from.

Take any technical skill - music, cooking, athletics, etc. - what exactly is a novice looking to learn? Someone looking to learn, say, self-defense is not interested in kinesiology or designing their our combative system. I just want to cook, vs. I want to create my own takes on dishes.

> In that sense, it’s more important to get a feel for theory and aesthetics of programming.

Unfortunately, I disagree and would say this is a fundamental difference in Eastern vs. Western style education philosophy. Western is a little more about the theory and understanding the why; however, I think it provides a weak foundational knowledge of how to translate theory to application. To paraphrase Mike Tyson this time, everyone has a plan until they get punched in the face.

My opinion is that giving students a stronger foundational knowledge in the beginning allows for us to speak theory later because I can trust that you have the ability to implement that theory.

Software architecture is composing absolutely. But, the tactics of coding are applying skills like being able to execute a solo or musical technique. The difference is that playing music well requires the player to 'forget' the technique and just play (relying on muscle memory).

I could argue that software developers probably leave some amount of untapped potential on the floor by not at least sometimes attempting to "forget technique," and instead dive into deep flow and get really ambitious about high level results, without engaging in explicit "technique," at each step.

Think about trying to spin up a purely mental model of an entire distributed system in your head, and then attempting to make deep, cross-functional inferences as a result of seeing the forest, and then solidifying those inferences into concrete, but super ambitious goals, instead of "incremental" goals, as everyone seems so fond of talking about nowadays. "Incremental" progress doesn't often produce paradigm shifts in the overall "game", and it's not the only way to approach problem solving.

I think this is mostly due to cost and risk, but I worry that this is an engineering "muscle" to be trained that we allow to wither away through lack of use.

Also, for the purposes of the article, you can even just discard the music analogy and focus on the four parts: you need some theory, you need time to work on your own projects, you need time to work on production code, you need to actually ship. We need a better balance of those things.

But I do think the analogy works well--it's like PG's analogy of hackers and painters.

Agreed. Composing music is a thoughtful process with review and iteration until a final release candidate (song) is made.

The author may be coming from a place where they don’t compose music but rather play existing music. Their analogy works I guess but I agree programming is more like composition.

Many song writers compose music but do not perform the songs.

Yes, my experience is mainly just performing. I haven't done any composition. Maybe if I had, I would've come up with some different analogies.

I think the analogy to playing music still works, though. You iterate on a piece by practicing it repeatedly, "adding features" (improving technique), "fixing bugs" (smoothing out passages where you often make mistakes), "polishing the code" (intonation, ornamentation etc).

That being said, maybe I should've picked a different title--the analogy to musicians was a source of inspiration for me but isn't really the meat of the idea, I think.

To be antipretentious, what about improvisation? It's an important part of many styles of music, and is a form of composition/performance.

Hacking is to programming what improv is to musicians. Free-flow, curious, toying with concepts and inquisitively seeing if they can be pushed beyond their normal expectations...