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!
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?”
Obligatory photo of Jack Sparrow. Entirely unrelated to Captain Code, who is much more intelligent.
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.
Sing to the Beatles “All you need is love”
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.
A borg, debatably.
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!
A sweet house in Cambridge we saw on our Easter walk.
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) 4. Stupid 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.
My Bloom’s Taxonomy Git skills are up from apply to analyze!
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.
A blurry action shot from 2010 of my quartet. We are all laughing at a page turn incident.
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: 1st violin 2nd violin viola cello
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.
The opening 8 bars of this string quartet have spawned (inspired?) doctoral theses.
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!
Paula Muldoon 