Afterwood

It’s a pretty tense time in the Oldwood household at the moment, much like many other families in the UK with children waiting for their exam results. Oldwood Offspring v4.0 (not his real name as we’re not that cruel) has had the pleasure of spending the last few months studying hard for his exams – luckily he didn’t follow in his father’s footsteps and wisely chose to listen to his siblings instead and put the time into revising the content and improving his exam technique.

What I failed to learn at school was that exams are one of life’s little games that you sadly have to play, at least until someone comes up with a better assessment strategy that doesn’t involve sitting silently in a room and having to remember stuff in a way that bears no resemblance to The Real World™. It’s also one reason why I’ve never been interested in the various certification schemes on offer, but that’s in part because I remember the 14-year-old back in the 90’s who qualified as a Novell Certified Engineer despite having little to no practical experience. Being able to regurgitate what a particular Windows API does is no guarantee that you can string Windows API functions and procedures together in a useful way to create a working program.

What is different about studying for school exams in the modern era is that you not only have easy access to lots of past papers, but also the marking schemes too. This is a real game changer as you no longer have to merely guess what the examiner might be looking for, you can actually look it up, and have a deeper understanding of how the game is played – ‘know thy enemy’, as Sun Tzu once advised.

One tip, which I had always assumed was some kind of perverse technique teachers used to make their life easier when marking, or slowing the bright kids down so they could have a bit of peace and quiet, was the idea of showing your workings. It turns out, after recently reading many marking schemes, that this is actually beneficial during exam calculations because you can still be awarded marks for the correct approach, even if you accidentally plug in the wrong numbers. In particular, failing to apply the correct units conversion might only cost you a mark, while still receiving the remainder for the body of the calculation. Examiners might be contented to treat unit conversion as a “nice to have” but I’m pretty confident that NASA takes it far more seriously after what happened to the Mars Climate Orbiter, etc.

Unlike eigenvalues and eigenvectors ¹, I have found the practice of showing one’s workings to be of immense value in the workplace too. Much as I enjoy the occasional game of ‘guess the intent’ or ‘reverse engineer how they achieved this result’, I’d rather be like the examiner playing along and validating the approach because, unlike the examiner, I don’t already know the right answer.

The most obvious manifestation of this is probably the writing of formal tests. When you only have the code to work from, and you discover a problem, without any tests it’s hard to know whether the author ever considered the scenario in question. There is plenty of code in the world that only appears to work purely by accident. Without any tests to work from you have an uphill battle establishing an initial set of ‘likely’ invariants before you fix the actual problem. At least if you have some tests to work from, you have the version control history of both the code and tests to consult, along with some degree of confidence that the author even considered testing the code. (People writing and pushing code whose correctness is only based on mental simulation is more common than you might think.)

Writing a test plan – either as part of story refinement, or appended to a commit message – is a practice which I have adopted more and more in recent years, especially when not pairing or working as an ensemble. We talk about reviewing the code, but rarely do I see people questioning the approach used to test it. The presence of new, or updated unit tests is a good sign, but as a more experienced programmer I find much of my time goes into pondering the Law of Unintended Consequences, i.e. what is not covered by the automated tests that might need special consideration. Sadly, “the unit tests pass” is the new “works on my machine”.

Where I find people sharing their workings particularly helpful is in the diagnosis of issues. Posting a screenshot of a log message or chart on a ticket is akin to just writing down the answer in the exam. While it probably is relevant to solving the specific issue, it takes very little effort to also include on the ticket the KQL query or Bash one-liner that led to the answer. If the resolution doesn’t seem forthcoming it’s then possible for someone to quickly review the approach, just like when testing, to check obvious things haven’t been missed. What I’ve learned from writing (in general), is that sharing my approach has, on many occasions, lead me to spotting my own silly mistakes before sending others off down the wrong path. In environments where issues drag on and handovers are common, your successor will thank you for not forcing them to derive everything from first principles before investigating further.

I know that ultimately I’m an automation junkie, and that I’m also a fan of the concept of marginal gains – my sixth sense is probably ‘I see automation opportunities everywhere’. Many of those opportunities start out as crude one-liners (puns not intended) and make their way into wiki pages and runbooks before eventually solidifying as tool. But I feel many other valuable learning opportunities are missed because the approach is locked away in someone’s head or on their machine. Marking your own homework might feel like a personal productivity win but you’ll never know if you could arrive at the answer quicker or more reliably in future unless you allow your peers to grade your approach too.

Footnotes

1. They eventually cropped up 20 years later when working on a finance gig, but luckily by then the only maths I needed for my roles effectively involved ++ and --.

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the comfort of his breakfast bar. He has resumed commentating on the Godmanchester duck race but continues to be easily distracted by emails and DMs.