I had a lot planned for last year.

We’d just moved to Zürich, and were getting to know the place. I’d found the good coffee, and I was on the hunt for decent Thai food. We bought some furniture, we didn’t have ceiling lights (now resolved), we’d figured out how to buy bin bags (it was a challenge) and I missed fish and chips. I planned to work on an open-source project, buy a TV, and jump in the lake a lot. I planned on buying a snowboard, and come winter 2020–21, learning how to use it properly.

Then… well, you know what happened.

I’ve been oscillating a lot, the past year. Some months were good. I exercised regularly, kept sensible hours while working from home (and I’m very grateful I have a job where I can do that), and practiced being a reasonable human being to the people who were forced to interact with me over fucking video chat (yes, fucking video chat). I did jump in the lake once or twice, and we found some excellent paths through the local forest that we could meander through on the weekend.

And then there were other months. The lost months. The months of always-on, low-level grumpiness, where the highlight of my day was eating more cheese while the cat judged me. The months of sitting until my back hurt, then complaining my back hurt and sitting some more to “rest” it. The months where an entire week would go by without me having a meaningful conversation with anyone past, “Do you like your coffee?”

So no, I didn’t accomplish all I set out to in 2020. I didn’t snowboard. I didn’t work on my highly secret open-source project. I didn’t get swole.

Last month, I turned 32. Like any round number, it inspired reflection on the past few years. And I realised that while I didn’t achieve a bunch of arbitrary goals, I did accomplish one thing without even noticing.

Possibly for the first time in my life… I feel pretty good.

Sure, not everything is amazing, and there’s lots more to do. I still want to learn to snowboard (without falling a lot), and I still want to work on my secret project, but I know that I can and I will. I don’t have to worry about them all the time.

I have a lot going well for me in my life right now, and it’s fun to celebrate that instead of always getting stressed out about the next thing.

Say one thing for 2020: it taught me how to be content.

Recently, I had the displeasure of experiencing a few interesting situations in which traps in zsh don’t run. This isn’t the first time I’ve wasted hours or days debugging this problem, so I’m writing it down.

For those of you who may not know, a trap is a catch-all exception handler. Think of it as a finally block for your shell script.

Try this script:

#!/usr/bin/env zsh

set -e

trap 'echo "Finished."' EXIT

echo 'Started.'
false
echo 'This will not print.'

This script will exit with a failure code due to the false invocation. This is because set -e, or set -o errexit, will tell the shell to exit as soon as one command fails. (This is not the default, or your shell would keep quitting on you every time you made a typo.)

It’ll output this:

Started.
Finished.

I’ve just released version 2.1.0 of Smoke, my integration test framework for command-line applications.

The major feature: if your command-line application produces files, you can now test their contents.

The release notes explain all:

Chipo, on the Codebar Slack, asked what they could expect in a technical test. I wrote a pretty long answer, which I thought might be useful to others as a blog post (after a bit of cleanup).

I’d typically expect a “tech test” to be part of an interview for a software development role. It involves implementing a small program, typically on the command line, as well as you can. Often, the interviewer will expect you to write unit tests and practice good design principles (low coupling, good names, etc.)

Sometimes the interviewer will send you an exercise to do and expect you to send the results back, and sometimes you’ll do it in their office (or online, over video chat and screen sharing) with someone looking over your shoulder. They’ll usually ask you to bring a computer if it’s the latter, but don’t be afraid to ask to borrow one (and specify the kind of coding environment you’re used to) if you don’t have one available.

I don’t have a plan, but I have half a dozen outlines for plans.

I recently made an observation about myself that I thought was worth sharing. It’s both an explanation of how I operate and a realisation of the trouble this causes for other people.

I’ve never really been able to collaborate with other people; either I do things on my own or not at all. I’ve managed to get over this to an extent with techniques like pair programming, which enforces a kind of working structure by breaking the work into small, manageable pieces together, but by and large I kind of suck at it.

Took me about 30 years to figure out one of the reasons why.