a violinist learns to program
This week was Rails week, and our remote cohort of 17 programmers from 5 countries working in 3 timezones spent a week making Acebook, a clone of - you guessed it - Facebook.
It was a great, if hard, week. My learning shot up exponentially. Also my ice cream consumption. Here is what I learned:
1. Red/refactor/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red is not a great cycle. Red, green, and ONLY THEN refactor. We spent a lot of time looking for bugs in our code when it turned out our partial was named incorrectly and Rails couldn't find it.
Polymorphic (alas, not paulamorphic, much as I love eponymous taxonomy) associations are really cool. I'm glad they're so cool, because here was the process in which my pair and I learned about them:
Build a PhotoComments functionality, almost wholly copying the already-existing Comments functionality. This was not remotely DRY, but we couldn't figure out how to get round the database issues. This took a whole day because of the aforementioned red/refactor/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red/red and we were super pumped to finally have it submitted for PR.
Our coach tells us that there has to be a dryer way and blocks our PR. His name is Dan, and he's a great coach because he made us go and find something way better. Was I still banging my head in frustration? Yes.
Help my landlord remove the old dishwasher that's being replaced and end up with a broken hose and water gushing out over the kitchen floor before I luckily had the presence of mind to switch off the water switch on the pipe. Not flooding the kitchen is possibly my proudest moment of the whole week, and I'm pretty proud of Rails. I did later get a bottle of prosecco as a reward for valiant behaviour, so all in all, a good week.
Have standup without coffee or breakfast (see Step 2.5) and decide to throw out everything we did yesterday.
Go to make coffee, forgetfully turn on the kitchen tap, and watch the water flow out everywhere. Put a tea cosy over the faucet so that doesn't happen again.
Google. It's a solved problem, so look for the most obvious answer:
This first searched proved extremely productive (newer searches first):
Use TDD to build a polymorphic database!
Be foiled in your attempts to merge your PR because of merge conflicts that can't be resolved in the ten minutes before retro.
Spend another hour that night working on all kinds of git conflicts.
Give up on resolving the merge and write a blog.
Still, polymorphism is really cool. And if you're still awake, you might be wondering what it is! Basically, it's a way of reusing code so that, for example, the code for comments could be used for both posts and photos. It defines the DB associations so that the comments are polymorphic, i.e. can exist with either a post_id or a photo_it. The Ruby on Rails Guide has a great section which we found really useful, and there are various other blogs with step-by-step instructions.
So I think that's it for Rails week. I'm building an Instagram clone this weekend, so I'd better get off the computer. I can't stand Instagram, so if you're very lucky, you might get a grumpy post from me about how I wish I could use Rails to build something more interesting this weekend. Or about how I tried to build something more interesting and ended up melting my laptop.
Read about the first half of Rails week: Buttoning Up Code: a valiant team uses TDD, pairing, and XP values to defeat a bug
This is the story of a bug.
This bug was annoying and caused the coders a great deal of heartache and misery.
The coders were tempted to give up on solving the bug.
But they persevered, and the bug was fixed.
This is also the story of Makers Academy, encapsulated in this one small story about a bug.
On Monday 29 May 2017, my pair partner and I submitted a pull request for the front end we had built and styled using Ruby on Rails 5. We were quite proud of our design, and rightly so. It was a clean, elegant user interface, modelled shamelessly on Facebook (our whole-team project was to build “Acebook”).
Our coach asked for some changes, one of which being to fix a test that had mysteriously begun to fail (first lesson learned: run your tests again before submitting a PR), the second to restyle a button class according to Rails syntax.
The first failing test was relatively easy to fix: a stylesheet had been required twice. Turns out you don’t need to explicitly require your stylesheet as it will be automatically required as long as it’s located correctly.
Which led to the second error: ‘unable to find button "New Post"’.
This error would drive us round the bend.
We could see quite clearly on the page that there was a button; we could inspect it with the chrome devtools and see its lovely button classiness.
And yet Capybara couldn’t find it.
I Zoomed one of my teammates, and when he couldn’t find the error either, I retired in defeat for the night. When we resumed the next morning, I showed the error to my full team of four and no one could figure it out.
So we called in the big guns: our coach.
We then spent a good half an hour exploring differences between Rails 4 and 5 syntaxes (‘form_to’ vs. ‘form_with’ anyone?), changed a lot of things around, and eventually reset the test and code to a point at which it was working. We couldn’t figure it out.
Eventually our coach said, “Sometimes you just have to say ‘that happened’.” That sure did happen. But there was one thing I couldn’t understand: why the test passed when it said ‘click_link” when the code was clearly a button, yet failed when the code said ‘click_button’.
Then our coach got the light in his eyes that said, “I now know the answer, and I am going to leave it to you guys to figure it out.”
Needless to say, I was annoyed.
I’d been plugging away at this error for a good three hours now, with several different teammates and lots of attempted solutions, and had gotten nowhere. I was at the frustrating stage where my code worked (I thought - I could clearly see the front end doing exactly what I wanted the test to do) but I didn’t how I had broken the test, or why it was working with the reset code.
At this point part of me still wanted to implement one of the two suboptimal solutions:
It was also lunchtime, which may have had something to do with my frustration.
I switched pairs to get fresh input and we plugged away at the problem and then all of the sudden it came to us in a flash - in fact, the bit of Rails magic was a link, not a button, which is why ‘click_link’ worked, even though this link had managed to get attached to a button class.
Great, so all we needed to do was to change ‘link_to’ to ‘button_to’ and be on our merry way. Simple.
Have you ever tried editing code from one unfamiliar syntax to another unfamiliar syntax while it’s lunchtime and your brain is fried from a morning of debugging?
We reconvened after lunch (in my case, a nap) and in twenty minutes had sorted out the syntax, the tests passed, and the browser looked fantastic.
The evil bug was defeated because:
The whole Makers Academy experience is summed up in this bug experience: pairing, TDD, XP values, and rigorous code review. I’ve never been so proud to be a MA student as I was today.
With thanks to teammates Jon, Miles and Sandy, to the rest of the remote April 2017 cohort, and to the MA staff.
Read about the second half of Rails week: Paulamorphism: tales from Rails
I did eventually learn to do cool things in JS, but what a sweet relief to be back in the land of Ruby, where there is a useful method for anything we could possibly want.
So I had a lovely romp in the park with my old, dear friend Ruby this weekend and now forward to making as many puns on the word rails ("keeping it rail", "the holy gRail") as I can possible manage.
Ever wondered what sort of structures classical music has? The answer is - loads! This week I gave a presentation to my coding cohort about sonata form. If you're curious to know what's going on with classical forms, check out the video below!
You'll want a Spotify account (free is fine) and if you like, you can follow along with the score as well. If you're not comfortable reading a 4-part score, I suggest following either the first violin (top line, treble clef) or cello (bottom line, bass clef).
Full score: hz.imslp.info/files/imglnks/usimg/2/26/IMSLP04758-Beethoven_-_String_Quartet_No.4_Dover.pdf
Have fun and post in the comments!
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.