a violinist learns to program
When I found out I was going to be pairing with "Captain Code", I was curious to work with this snazzy computer program that would somehow mysteriously assist me in my programming learning. I envisioned a chirpy little bot that would come out with such pearls of wisdom as, "Ahoy there, are you sure your constant is defined, matey?"
Needless to say, Captain Code is a loveable pirate captain who retired from the high seas when his wooden leg was destroyed in a cricket match. He has a keen eye for detail, drinks just enough rum to be constantly jolly, and was never a very good pirate because he chatted too much to his captives, became their friends, and let them off for absurdly low ransoms. His profit margins were crap so he reinvented himself as a programming coach and joined a ukulele band.
Turns out Captain Code is a polite way of saying, "You're on your own today."
So after 2.5 weeks of intense pair programming, today I became a lone wolf coder.
To be honest, I was really looking forward to today. I have found the pairing process rather exhausting, being in such close contact with another human being for so long. And while I've certainly grown better at it, and worked out when to take breaks and how to communicate to make the experience successful, I was delighted to have the chance to work untrammelled by a pair's lunch schedule.
So here's my run-down of a day of solo coding.
What went well:
1. My own schedule! I took my lunch break when I wanted it!
2. Pomodoros - I was really disciplined about 25 minutes on and 5 minutes off, and that timer really helped make my day productive.
3. Error debugging - I hit a stride today in debugging errors/fixing failing rspec tests.
4. Code production - I finished the Single Responsibility principle, so am very happy that I've come this far.
What didn't go so well:
1. I was lonely. I figured working on my own would be a walk in the park, after many years of practising violin 4-5 hours a day alone. Turns out I like talking to people, and this was the first day on the remote course I felt like I wasn't getting enough human contact. This loneliness had a cascading effect:
2. I was grumpy because I was lonely.
3. I struggled to take breaks, because I was already grumpy so kind of figured I might as well keep on being a grump, and my grumpiness wouldn't affect a pair. (I took 5 minutes because of my pomodoros, but really would have benefitted from longer breaks as well.)
4. Accountability. I didn't slack off, but I really wanted to take an hour-long nap or watch TV and finish coding in the evening. This isn't an option when you're pairing, so the temptation never comes up. So I wasted mental energy combating this desire.
5. Not having a pair means you miss obvious things! I had to ring up my coach because of an absurdly stuck test and he spotted immediately that "Borg: 3 LS" and "Borg: 3LS" weren't the same - a pair would have spotted it.
I had wondered if the pair process was the best way of learning - it can be unbelievably frustrating to be at a different stage (whether higher or lower) than your partner - but after today, I can definitely say that I'd rather the frustrations and trials of pairing than doing much more solo coding.
So cheers to my cohort for being full of awesome pair partners!
This weekend's coding challenge involved writing a lot of rspec tests. I got stuck pretty badly. In fact, am still stuck, hoping my coach can respond before I submit; I have shown my test to two cohort peers who couldn't figure out what was wrong, and I do have a few more suggestions to try.
Having been stuck for about 72 hours, I feel the following:
1. Like a failure
2. Like I've wasted my money on the course
3. Exhausted (partly because it was Easter weekend and I had a lot of company, all of which was wonderfully fun, but which was tiring as well for this outgoing introvert)
5. Worried I won't get a job because I got stuck in rspec tests and couldn't figure it out
To put matters in context a bit, I am used to working hard but not used to struggling - a key distinction. I graduated from university with highest honors and I had a successful career as a violinist. While at university I took hard courses but in topics that were my forte - English, music theory, Spanish, and of course violin. I steered clear of math and science because I didn't have a very good math/science background and I was afraid of getting a grade lower than an A.
So Makers is the first time in my life that I've stretched myself to work outside of my comfort zone. I have to remind myself that I started violin lessons when I was eight and had many, many years of focused, individualised training that enabled me to reach the standard I have. I've been coding for 5 weeks. Of course all of this is new, and of course I should be struggling.
Struggling is hard. I have been realising over the past 72 hours how much of my identity is wrapped up in being right. I feel emotionally exhausted, and not just because of rspec and because I am outside of my comfort zone and struggling: because I have realised that so much of my identity throughout my life is wrapped up in being right that the thought that I might not always have the right answers to more important questions (such as personal relationships) makes me a bit sick.
I watched Brene Brown's Ted Talk on vulnerability yesterday and the thing that really struck me was how vulnerability and the absence of certainty are so related. If you're certain about being right (or even wrong!), you're not vulnerable. And without that crucial, scary, uncertain component of vulnerability, deep connection with other humans (and, I'd add, with oneself) is impossible.
So here's a baby step towards vulnerability, courtesy of rspec: I don't know the answer and that's ok because people will help me to find it.
Update: the story does end on a good note. My coach and cohort came through and I was able to resolve the errors and finish most of the problem.
So week 1 at Makers Academy has finished. Whew! In the bizarre time warp, I feel like I have learned 8 million new things, that the course has lasted several years, and that there are 800 million new things left to learn.
So here's a recap of what I learned:
1. Rest is good! The few days left me absolutely knackered. My brain totally stopped functioning (force quit?) at 6pm and I fell asleep at 9:30pm. Pairing is intense! But I resisted the feeling that I should keep working until midnight and that was definitely a good call. By day three I felt I had gained stamina, and although my brain still was tired by 6, it was less tired. Today I think I might manage to do some work in the evening! And I also got up at 6:30 to take advantage of my morning productivity time.
2. Multi-tasking is not good. Chatting online to your friend while also trying to sync your local git with the remote means you get into mild trouble. I didn't do anything I couldn't fix pretty easily with the help of my cohort (thanks, Dan and Jon!) but I learned the lesson: focus on one task.
3. The remote course offers unique ways of socialising! Last night I had Zoom drinks with a few fellow coders (the max you can really do logistically is probably 4), which was great fun - I was tucked up in bed with a glass of rose and we all chatted and geeked out and had a great time, with no commute home after.
4. Meditating and Alexander technique are a fantastic combo. My routine for the week has been:
8:40 - 8:50 lying on my back with a book under my head (classic Alexander tech)
8:50 - 9:00 meditation with a pair partner
I'm breathing so well! Next week I'd like to incorporate another 20-minute chunk either at lunch or before bed.
5. Making breakfast and lunch (especially lunch) is a total waste of time. I ordered a shipment of Huel (complete nutrition shakes) which should arrive today, complete with a free shaker bottle and Tshirt (to be added to my Tshirt rota, of which more in a later post). Hopefully it's not gross, and then my lunchtime can be put to better use (i.e. going for walks and/or meditating/Alex tech).
6. It's good to go in-depth into a single topic rather than having a superficial knowledge of a lot of things. My pair and I spent most of yesterday working on Git/Github, running into all sorts of fancy problems. We used our time well - we got majorly stuck, but all of our research was logical and to the point and when we finally called for help, our coach assured us that we definitely should ask for help before doing a hard reset! So although I didn't do much Ruby yesterday, I'm WAY more confident in my Git skills.
So my takeaway from this week? Learning one skill/concept thoroughly is much better than learning five superficially. Going slowly is ok. I'm never going to learn it all in 12 weeks anyway, so better to learn some things really well and experience the process of gaining mastery (of a sort!) with a topic.
I'm always curious which lessons from my 22 years of playing the violin can be usefully applied to programming, and the 6-step assertive communication post that one of my cohort shared got me thinking about the ways chamber musicians communicate.
For the uninitiated, chamber music is a small group of musicians (3-8 people) who play the absolute best music ever. The dynamic is very interesting: take the most standard form, a string quartet. String quartets consist of:
The old joke "What does a string quartet consist of? A good violinist, a bad violinist, a former violinist, and someone who hates violinists" may have a small kernel of truth. In some pieces (particularly in classical, i.e. music from roughly 1760 - 1815) the first violin basically plays a difficult solo and the other three voices accompany. But in most pieces, all parts are equally important BUT they trade importance - at one point the cello may be the main voice, then the viola, and so on.
So to function effectively in a quartet, you always have to be aware of:
1. Who has the main voice at that particular moment
2. Who will have the main voice next
3. If you're not the main voice, how prominent should your role be/how can you add to the mixture without overpowering?
Quartet members have many different communication styles: some (like me) like to talk a lot, to intellectualize, to explain, to understand the theory. Others like to demonstrate simply by playing (and frankly, your playing should be enough in an ideal world, but sometimes you have to hash things out verbally), others are a mixture.
Quartet is very intense - if you think pair programming is intense, imagine quartet programming and you have an idea of what it's like. String quartets have been (justly) described as a marriage between four people.
So how do you communicate?
(NB: This is my experience - not at all intended to say it's the right or only way - and I'd be really interested to hear from other chamber musicians what their thoughts are.)
First question: Is the chemistry good or not? If your musical styles don't have some coherence, it's probably not going to work. Quartet is all about learning and improving, but there has to be some basic agreement or else some MAJOR flexibility.
If the chemistry isn't good, well, smile, get through it, and hopefully the next time you'll have better partners. (That could be a different post - how to handle a situation where the chemistry isn't great.)
But if the chemistry IS good - things get different.
1. Fundamental rule: listen more than you talk. You'll probably end up with an equal balance but it's really important that the focus be on the other person's ideas and playing. This means that the other people feel heard, and important, which means that they will contribute with 100% energy.
2. It's clear whether you respect someone's playing, and if that understanding is there, you can be a lot more direct. With people I really trust and whose playing I adore, I have no problem saying, "Why are you doing that? Doesn't sound good." They know I love their playing and I am simply trying to make it better.
3. Culture matters. Americans and Dutch, for example, are much more likely to speak like in #2 directly whereas the English might say "You sound absolutely spiffing, my dear chap, but just wondering if you might possibly consider doing it this other way just the once, although I'm sure it's absolute poppycock?" Be aware of these differences.
4. Always try the other person's idea with 100% enthusiasm. One of my favourite quartet memories was in undergrad when my cellist and I had opposite ideas about how a phrase in a Brahms string quartet should go. We tried both ideas with such conviction that at the end, we preferred each others'! There's usually more than one way to do something, and trying someone else's way means you learn.
5. If there are two equally valid ways to solve a problem or approach a situation, choose the way the other person wants. You'll learn something, and the other person will feel validated.
Right, that's it for now - may update more as the thoughts occur!
Makers Academy day 1 of 60 (not counting weekends) is finished. It's 8:45pm and I am in bed absolutely exhausted and very happy.
We had orientation this morning, learning about how MA functions. It was great to see their intelligent approach to learning and even better to hear from Dana, our Chief Joy Officer (meditation/yoga/life coach). I'm so glad MA encourages us to take care of ourselves!
Then I had a fantastic Alexander technique lesson over lunch, which really helped with some left shoulder issues I've been having.
And finally, spent 4.5 hours pair programming. It was an intense experience! Learning to work in close proximity with another human being is always a learning curve but years of playing chamber music have really helped to train me in listening and communicating. We both thought our pair session went really well, we had a good feedback session, and are going to chat on Slack tomorrow morning about what we learned.
The actual coding itself was pretty easy, which is good - the focus was on learning to pair effectively. Am looking forward to some deeper coding challenges!
As soon as we hit 6pm my brain just shut off. While I wanted to do another 5 hours and totally finish the week's challenges on day 1 (afternoon 1 even!) all of the sudden none of the words on the page made any sense to me so I had to call quits on the session :) .
I then went on a walk for an hour to appease the FitBit gods (while chatting on the phone to a friend, conveniently), came home and ate bacon and porridge for dinner (yum!) and now am struggling to stay awake till 9pm.
So what have I learned from today?
- I need to read instructions, code, and error messages slowly. I read far too quickly and get away with it a lot, but what's the rush? Where's the race? Better to do it slower and more mindfully. Hm, mindful code reading...
- I am very much eyes on the prize - complete the challenge the recommended way before finding other ways to do it. I do think this approach is borne out by Bloom's Taxonomy - master the apply stage before moving on to the analyze stage.
- I really can't sit still. In 4.5 hours of pairing (including breaks), I moved from the desk to the floor to lying on the floor (not great for typing but ok for navigating), back to sitting on the floor and ended up at the desk again. I apologise to everyone I am pairing with that I will be roving around.
- I need to wear more comfortable shoes when walking.
Bye for now!
Today's lesson is knowing when to quit. I passed a very pleasant evening working on a regex kata. I read half of the Well-Grounded Rubyist's regex section numerous times, parsing out each individual bit of code, I read Stack Overflow answers, and all kinds of other stuff. I wrote my own tests and code.
I couldn't get it to work.
After an hour on this problem, I should have either stopped working on it or asked for help. I did neither. I kept going.
After two hours, I realised I needed to ask for help. But by that point, I had reached the "try random things" phase of programming, which meant I kind of had no idea of what was working and what wasn't.
THANKFULLY I had at least committed some useful code but I spent another half hour struggling on my own because I knew at that stage asking for help would actually be difficult - how to recount what I'd done when for the last while I'd been just chucking in semi-random bits of code?
So lesson learned: don't spend too long on a problem because it becomes counterproductive.
On the other hand, I am fully immersing myself in the student life - including subsisting on pizza and ice cream.
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.