a violinist learns to program
In the music industry, we have a saying: RTFS, which stands for "read the f***ing schedule". It's mostly used on tour, when you roll down to the hotel breakfast after a late night concert and ask your equally tired colleague, "When does the coach leave?" "RTFS!"
Well, I have a new version for myself in coding: RTFI, or "read the f***ing instructions."
I spent 90 minutes this morning working on a Code Wars kata. I skimmed the instructions a couple of times, and was pretty confident I knew what I was supposed to do. So I built my own TDD tests, and proceeded along my merry way writing the code.
Before too long, I had passed all my own tests and was satisfied with the code so I ran it through Code Wars. Failed one test, ok, no problem, can fix that. Then I failed another test. Now this particular kata had you build your own tests so I couldn't tell what argument my code was being passed that caused it to fail in so many different and spectacular ways.
I thoroughly ignored the advice of my cohort pal (sorry, Rob!) who rightly insisted that the order of the elements in the array mattered, because I was convinced I understood the (in my defence, rather poorly written) instructions.
After more tests failed, I went to look at the instructions again and lo and behold, I had been building the wrong thing. Needless to say I was by now too frustrated to get any useful work done so I'm writing this blog post instead as a warning to future Paula:
This week 3 blog is coming out in week 4 because I turned a corner in coding this week: it was the week I started preferring to write code over blogging.
This may not seem like a big deal, but it is - I LOVE writing and for the first two weeks, I would have much preferred to write about my coding than to actually code. Now it's reversed, and although I still love writing, I'm actually kind of irritated that I'm writing now instead of coding.
But I think it's also really great to document what's going on, so here goes.
My week 3 experiences:
1. It was much easier than week 2 - I was able to put into practice a lot of what I'd learned in week 2 and it all made sense.
2. Each day is so full of new coding knowledge - I was looking back at week 2 programs and they seemed laughably simple. This is encouraging, because at the time, they felt hard.
3. I was pretty disciplined about not working too hard! I know the course is about to get intense, so I made sure to get all the work done that I needed to do, but I also made sure to enjoy walking around, getting time in the sun, and chatting with friends. All of this is really important to give my brain time to rest from all of the intense learning I've been doing.
4. My FitBit is still great - it's making me walk more, and walk the long way round to things, just to get in all those steps.
5. My violin recital went really well! It was super fun to play my own piece (Yankee Doodle Variations for Solo Violin, which I wrote last summer after an ice cream truck drove by my house every day for two months playing Yankee Doodle) and, despite not having played a solo recital in a few years, I wasn't nervous at all. My pianist Tim was great to play with and we'll definitely play some more recitals. So it's wonderful that I will still be playing violin for fun as I become a programmer.
6. Also in violin/book news, I did 8 hours of recording sessions on Saturday in London. My train was quite delayed so my planned 20-minute excursion to Daunt Books en route to Air Studios at Belsize Park had to happen in three minutes. In a beautiful meta-comment, I bought a book on split-second decision-making ("Blink", incidentally the title of one of the scariest Dr Who episodes). The only problem is that I am now reading eight books simultaneously, all of which are fascinating. Need to focus!
Ok, now I think I have earned some coding :)
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.
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
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.
So I've finished my second day at Makers.
What I have learned so far:
1. My cohort's hive mind is great. We share information and it's wonderful to have access to their intelligence and drive.
2. Leaving a problem for an hour and returning can magically make the problem go away. I was starting the mystery for the week, and literally couldn't figure out what step one was. Nothing made sense. So I cycled out to drop my violin off at the luthier for repair (it sounds terrible, am hoping it's just an open seam and not a crack), got some apples to make pie for American Pi(e) day, meditated, and then hey - GitHub, the command line, pushing, cd.. ...it all started making sense.
3. Diving into the command line takes away the fear and uncertainty. When I started doing the command line exercises, I really missed Ruby and the logic of programming. I felt like the command line was a bit of an annoying distraction from the main fun of coding, and it also looked like a lot of gibberish. Having spent a day with it, I know it a lot better. Also, changing the font to pale green on a black background definitely helped, as did making the text size bigger.
4. Starting the day with a walk around Cambridge is fantastic. I met a friendly cat, got a free map of the Sussex Downs, and saw some really beautiful houses
In non-programming news:
1. I have a violin recital on 2 April. This will be pure joy, but it's difficult to be motivated to practise, mainly because my violin is currently making dead cat noises (hence the trip to the luthier). Hopefully he can sort it out and I'll enjoy practising again.
2. I walked over 8,000 steps today. I definitely would not have walked anywhere near this if it hadn't been for my Fitbit. I am going to up the goal to 10,000 next week. I am still last in my competition but hey - I'm moving.
3. I made a pie for American Pi(e) Day! It wasn't my best pie (a bit out of practice, especially since I've been eating more healthily), but my landlord's dinner guests were very appreciative nonetheless.
Today I'm starting my first day of the Makers Academy programming course. (Pictured above: CodeAcademy Ruby study in Canterbury - I programmed for 4 hours before playing a rehearsal and concert with the Philharmonia Orchestra.)
Starting this course is scary and amazing. Scary because what if I turn out to be crap at coding and I spent a lot of money for nothing? Amazing because I'm pretty sure I'll keep loving coding and it'll be a great change in my life.
My prep for coding has consisted of:
Buying nerdy Tshirts so I will have a coding "uniform" to get my brain into coding gear for when the full-time course starts. The shirts will be arriving soon so you will see photos in a later blog.
Buying a FitBit so that I stay active during the course (I love walking and exploring Cambridge, and I will be kicking my 8,000 step goal out of the park). It also allows me to track water, nudges me every hour if I haven't moved, and does a guided 2-minute breathing meditation. (One of the things I loved about MA was its commitment to students' wellbeing - I totally agree that people learn better when their brains and bodies are taken care of!)
Buying a MacBook Air. WOOOHHOOO!!! I am a MacMommy! I have named it Emmeline (after the suffragette Pankhurst) Skål (the Danish word for "cheers", but also the Danish word for skull, because, you know, Vikings drank from skulls).
Now I'm off to learn some code!