As a musician myself, this post resonates with me.
The place I'm currently working for is the first employer that, at least somewhat, encourages experimentation and practice. And even here, it's not really company culture, it's just a manager that "gets it" i.e. allows 20% for "other projects". You can tell that the employees that are looking forward to that 20% are the ones coming up with novel and interesting ideas for the work-related projects and are generally performing better.
This is going to sound pretentious, but programming is closer to composing than performing.
Source code does not store any performance metadata, just the static score. In that sense, it’s more important to get a feel for theory and aesthetics of programming.
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).
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.
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.
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.
> 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.
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...
No idea why you were downvoted. I have been a programmer and a musician for over 35 years, and I totally agree with your summary above. I use music as a recovery tool from programming because it prevents mental burnout for me. Both activities 'exercise' a different part of my brain to keep me balanced.
That's my case too, though I'm not sure that I distinguish between feeling and thinking. But playing music is how I recharge my mental batteries. Not only does it exercise a different set of thought processes, but it also demands enough of my attention that I have to stop thinking about work. And it also gets me out of the typical techie social milieu and into a wholly different cast of characters.
the analogy with "listen to music" is not "read the code" it's "use the program" but definitely composing and playing don't use at all the same skills as programming. For example it's easy for me to see where a bug is but when I compose music, I hear something sounds wrong, I don't know if it's "un-harmonious wrong" or "interesting wrong" and a piece of music doesn't "work" for me the same on 1st listen, 3rd listen, etc... whereas a program is by essence repeatable. And as a result I don't really attempt to "fix" wrong music if I feel I went wrong with an idea I just make a new one. Whereas with code I was debugging from the start, even when I was new and unconfident.
"The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.
John Locke, An Essay Concerning Human Understanding (1690)"
I feel this is much more applicable to SRE and Ops Engineers where performing, rehearsing and practicing is much more applicable.
Where I work, SRE work on their own tooling that is synonymous to releasing. They rehearse in the form of conducting weekly drills like failovers. The rest is similar to what is written in OP.
For releasing, I wasn't thinking so much about the actual act of deploying the code. I meant getting code to a state where it's ready to be shipped and used by customers. It's important to break yourself out of the perfectionist tendency to just keep improving code and never releasing it.
One thing about both programming and music is that they both offer alternatives to the mainstream academic learning environment. Learning either of them can be self paced, and there are options for doing it through teachers, the Internet, in groups, or just alone with a guitar and a record player.
And it's fairly easy to assess your own progress, at least up to a point, and take your rewards as they come. You can also begin doing these "for real" whenever you want.
So it doesn't shock me if a person who seeks out programming for some of those reasons, also seeks out music.
Product development is a very creative process. I share many of the challenges that artists of all kinds experience, from novelists to musicians or painters. There are highs and lows, doubts and fears. I am never satisfied with my work yet move on because I must.
This analogy might make a little more sense if musicians never performed live and your audience didn't care if you cut and paste everything together from large libraries of sound samples.
28 comments
[ 2.7 ms ] story [ 53.6 ms ] threadThe place I'm currently working for is the first employer that, at least somewhat, encourages experimentation and practice. And even here, it's not really company culture, it's just a manager that "gets it" i.e. allows 20% for "other projects". You can tell that the employees that are looking forward to that 20% are the ones coming up with novel and interesting ideas for the work-related projects and are generally performing better.
Source code does not store any performance metadata, just the static score. In that sense, it’s more important to get a feel for theory and aesthetics of programming.
But I do think the analogy works well--it's like PG's analogy of hackers and painters.
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.
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.
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.
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.
when you read the code you think
programmers are not composers; they are scribes.
when you play music you ???
when you write music you ???
when you write code you ???
when you debug code you ???
Doesn't seem like the answers would be the same in every case.
There's a John Locke quote at the beginning of SICP that describes both very well IMO.
"The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made.
John Locke, An Essay Concerning Human Understanding (1690)"
[0] https://mitpress.mit.edu/sites/default/files/sicp/full-text/...
Where I work, SRE work on their own tooling that is synonymous to releasing. They rehearse in the form of conducting weekly drills like failovers. The rest is similar to what is written in OP.
I feel tricked. xD
And it's fairly easy to assess your own progress, at least up to a point, and take your rewards as they come. You can also begin doing these "for real" whenever you want.
So it doesn't shock me if a person who seeks out programming for some of those reasons, also seeks out music.
Yeah that's a load of crap. I have my own set of personal projects, but I know plenty of great programmers who don't. This is pretentious.
On a semi-related note, my blog uses computer science to analyze and generate music: http://jsat.io
(Does that count?)
Edit: Because banjos, like Rodney Dangerfield, get no respect.....