The River Cam

​So I’ve finished the second week of Makers Precourse. Not gonna lie, this week was a lot harder than last week. I have finally dragged myself through the 40th chapter of Learn Ruby the Hard Way and a kicking back with a well-earned Franziskaner. FYI, LRTHW is hard, and I just bought Chris Pine’s Learn to Program on Amazon, in actual book format which I shall mark up with a highlighter, because I think I need more practice. I even went back to Code Academy to have a look at their explanations for things — boy is anything easier than LRTHW.

My thoughts from this week:
– Fixed growth mindset is so important: our coach shared this fantastic Ted Talk which you should all watch.
 https://www.ted.com/talks/carol_dweck_the_power_of_believing_that_you_can_improve .

The phrase “effort + difficulty = new neural connections” really resonates with me. Programming is hard, but I look back on this week and I think of all the things I’ve learned that I couldn’t do before and that’s pretty cool.

— Some katas on Code Wars are easy and some are beasts. Choose wisely, and take an ally.

– Pair programming is great. I did my first pair session today and having another head on a problem is really helpful.

— It’s really important to understand what a piece of code does, rather than just call it blindly. Thanks to Gus, who spent two hours explaining arrays over Slack to me to make sure I REALLY understood everything before calling a function to do the dirty work for me.

— However, why not take the programming outside and work through with a pen and paper while being surrounded by daffodils?

​ — I might have given myself a pep talk as though I were a Starfleet officer.

— I’m trying not to go too crazy on the Precourse, simply because I know the course is going to be MEGA intense. So stopping when my brain says enough and making sure to have fun is important!

— My FitBit is totally getting me out of the house!

Until next week
​Paula

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:

Similarities:
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.

Differences
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.