I’ve been thinking about how my violin skills can help (or hinder!) my programming. Thanks to over twenty years of musical training, my brain is programmed to do the following:1. Search for patterns.
2. Pay attention to minute details.
3. Process multiple streams of information, mainly aurally but also up to about eight different written inputs, and also visual signals from a conductor (including deciding in a split second whether the conductor’s input is useful or not!).
4. Execute the results of the “program” (i.e. the written music) in a timescale, in a coordinated effort with up to 80 other people. Execution means a) choosing which of four strings, four fingers, and roughly eight positions (which I believe is 128 possibilities, but someone correct me on the math if not; and bear in mind there is generally more than one way to execute, so this split second decision also factors in stylistic and other concerns). Furthermore, I have to understand and implement the duration of a note, both in a strictly metronomic sense and also accounting for any flexibility someone else in the group may decide is expressive.
Consider the following piece of music, one which every violinist will know by heart.
Lots of different rhythms, pitches, all sorts of variables to be executed rapidly, accurately, and in coordination with a large group of people. Seamless integration of all the different streams of information is child’s play to an experienced violinist at the top of her game. Even a less familiar piece rapidly sorts itself out into patterns that my brain recognises and executes.
Now consider this screenshot of the command line:
Two colours (different colours, but neither one uses colours to indicate anything)
Text reads from left to right and top to bottom (except when the command line lists files, which it does in columns)
Details make all the difference — a missed “ . “ in coding can stop a program from running while a missed “ . “ can mean an incorrect note length.
Command line has no timescale
When reading music, I observe the following sequence:
1. Glance over the whole piece to get an overview
2. Mentally note any difficult spots
3. Play the piece, reading each line from left to right while keeping my eyes at least one measure ahead of where I am currently playing (this requires short-term memory to be functioning!)
When reading the command line, I find I often forget step three. It’s frustrating how slowly I read code — I’m used to reading music very quickly — so I try to solve problems using just steps 1–2 without really going through each line. So my next challenge is to accept that for a while I’ll be slower at reading code but that the time invested in learning to be really fluent will pay off later.