on by

I met a duck while taking a walk this evening.

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.

on by

Originally published in April 2017.

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!

on by
Me as a kid atop my brother’s car.

Originally published in April 2017.

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!

on by
Cambridge is beautiful in the springtime.

Originally published in April 2017.

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

on by

Originally published in April 2017.

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:

RTFI!

A random photo of me in a cowboy hat.