Yesterday I had the sheepish* experience of spending a couple hours trying to work out why the code I had committed in a working state suddenly stopped working. So I thought I’d write a blog post about how to debug this mysterious situation! While some of these scenarios are less likely to happen in local development, they can definitely happen in production, so if, like me, you believe in “You build it, you run it”, this can help debugging the live site as well!

What happened to me?
I was writing code to manipulate MS Word documents. I had automated tests that checked the XML of the MS Word, but for sanity, I had a local output for the file so I could open it and visually check it. I committed my changes in a working state, went to lunch, and came back and…the tests were all green but the output file was missing the changes. I tried a bunch of things that had previously caused weirdness with MS Word (hint: MS Word is really tricky to work with), ranging from invalidating my IDE’s cache, killing all the gradle processes, wiping the output folder, and a lot of swearing. I eventually realised the problem was that I was using parameterised tests, but not parameterising the NAME of the file I was outputting…so it was overwritten with each test run, and the last run had an empty input which (correctly) resulted in no change to the MS Word document. Cue more swearing.

So let’s talk about times when things mysteriously don’t work, and what some of the causes can be.

Cause 1 – external files
If you are working with input or output files, here are some questions you can ask:
– If reading from an input file, has the file been saved before being read?
– How is the output file being named?
– Is the output file path exactly what I am expecting it to be?
– Can the data in this output file be modified by another process (check out concurrency control)?

Cause 2 – software versions
I once worked in a company with a couple different codebases, each one of which used a different Node version. If you forgot to switch the Node version, you’d get weird errors (hint: there is a way to automatically switch versions on *nix – check out .nvmrc). Some questions you can ask:
– Could switching directories cause my current software version to be incorrect?
– Does this code depend on an external dependency which may have changed its version?

Cause 3 – build issues
Your code probably relies on some built dependencies. Some questions you can ask:
– Are all the dependencies built and where I expect them to be?
– Can I verify that each step of the build process is working as expected (implicit: do I know each step of the build process)?
– Is something interfering with my build process?

Cause 4 – asynchronous issues
I recently wrote a test that reliably failed every other time it was run. The problem? Part of the test relied on an unzipping process that was a bit slower – so by the time the assertions were run, the unzipping hadn’t been finished yet and the input files weren’t present. I ran a cleanup process to delete the files, but the files weren’t present by the time that was run either – so they hung around for the next test run. Some questions you can ask yourself:
– Is there any part of this process that will take longer than other parts?
– Could the capability of my operating system / hardware be slowed by some other process?
– If my tests rely on an external connection, is the network down?
– Is a remote server down?

And when none of these questions leads you anywhere, I have also found copious amounts of swearing usually do the trick…as long as I leave it for a few hours and come back to it.

*Extending the definition of sheepish to mean “something which cases me to feel sheepish” as “sheepifying” just feels so wrong.

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!

Originally published in April 2017.

The view from St John’s College, Cambridge — taking a tea break from a rehearsal

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 🙂

cheers
​Paula

The lush grounds of Madingley Hall, where I played my recital and also had an excellent roast lunch.

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:

Similarities:
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.

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