If you asked me the one thing you could change to improve your code, I’d tell you you’re asking the wrong question.

If you came to me and asked me how to improve the productivity, happiness, and knowledge of your software developers, I’d tell you that I don’t know. But I do know how you can find out.

Introduce pair programming, with frequent rotation. Pairing has a number of benefits that any XP fan (like me) will happily go into, such as getting very fast feedback on your work, keeping each other motivated, and learning how any part of the system works very quickly. I think an even more important benefit that doesn’t get talked about enough is that pair programming is a culture accelerator.

In a team (or company) larger than 5 people, 1 person can’t change much. However, a pair of people that agree on something can talk to others. With pair rotation, those 2 quickly become 4, then 8, and good ideas spread to the point where everyone agrees within days, without calling a meeting or needing a particular person to be some kind of champion for a cause.

Pairing, with rotation, means that a good idea in one person’s brain quickly spreads to everyone’s. When you’re pairing, you don’t complain about something, you improve it. That includes your company culture.

Don’t try and improve your developers' productivity. Make them do it themselves.

Booleans can be confusing.

Hold up. `diff` returns true if they're identifical?

😭 pic.twitter.com/6bmOInnKMz

— David McKay (@rawkode) May 11, 2021

Now, let’s first establish that we’re glad the file_diff crate exists and we appreciate the maintainers for their time. This is not an accusation or criticism of their work, simply an exercise in imagining a different universe where the API of diff is different.

So, with that in mind, let’s imagine we are reading some code that uses diff, and we are confused, just as David was. There are a couple of ways we could improve this situation for comprehensibility.

For example, we could change the logic so it returns true when the inputs are different (as implied by the name). That’d work, but then it’d have different behaviour to the diff or git diff programs, which exit with the code 0 (success) when the input files are identical.

Or we could rename the method is_identical (suggested by Stéphane Bjørne). This would make the return value more meaningful, as we can infer from the name what true means.

I’d prefer not to use true and false at all.

Semantically, what are booleans, anyway?

This might seem like a strange question. Truth and falsity, as concepts, are pretty ingrained in us. It’s not just computer people that use boolean logic all the time.

if (it's raining) {
  I pick up an umbrella on the way out ☔️
}

if (it's morning || (I'm tired && not (it's bedtime))) {
  I make coffee ☕
} else {
  I grumble about not having had enough coffee 😫
}

These two examples give us a lot of information about what a boolean is, in terms of what we can do with it. We can “and” (&&) them, “or” (||) them, and not them. (And other stuff, too.) But more importantly, we can if them. We can decide to do something if a boolean is true, and to do something else (or nothing) if the boolean is false.

I like to keep even traditionally system-level dependencies isolated and pinned per-project, so I use Nix for that.

I have been playing with Agda for a while now, and it has been a joy to work with a theorem proof assistant for the first time. (I am hoping to write some more on the topic when I am more familiar with it, but for now, I’ll just recommend Wadler, Kokke, and Siek’s excellent and free book, Programming Language Foundations in Agda.)

I found it a bit of a pain to configure Agda with Nix, and I haven’t found this advice anywhere else, so I thought I’d document it so someone else searching for the same thing doesn’t struggle quite so much.

I am assuming, for the sake of this guide, that you are using Agda with Emacs, which is the only real way to use it due to its heavy editor integration.

So, follow along to set up this combination of incredibly niche tools that you almost certainly have zero interest in. 😜

I got some praise yesterday. A colleague of mine told me that I never shy away from the hard problems.

It’s hard not to have a big grin on your face when you hear something like that.

Got me thinking though… what’s hard, exactly? And so I’ve been musing. Aren’t all problems hard?

Say a customer reports a bug, and you’ve got to fix it. You can fix it. You know you can fix it. Maybe it’ll take an hour, maybe it’ll take a day, maybe a week. But you’ll narrow it down, figure out the smallest possible increment of work you can do to remedy the problem, and then you’ll do it. And as much as it pains me to say it, because I want to be able to check that box that said I did the thing… this is the easy part.

Once in a while, when we’re feeling brave, we also try to tackle the hard problem. We try to answer the questions that we usually avoid.

• Why was this bug caused in the first place?
• Did we know about it before the customer hit it, and if so, why didn’t we do anything about it?
• Was the customer upset? Did we make sure they’re happy again?
• Can we fix not just this bug, but all classes of this bug in the future?
• What are the root causes ingrained in our culture that made this bug possible?
• Can we change our culture to ensure this doesn’t happen again?

These are the hard problems. We can’t always solve them. Maybe they’re too entrenched, maybe you don’t have the power, maybe others don’t see the problem, maybe they’re too expensive to fix. Or maybe you just don’t have the energy to fight this battle. We can’t fight all of them, after all. That way lies burnout.

But every so often, we tackle a hard problem, and we make just a little bit of progress. And whether we do, or we don’t, I think the fact that we sat up, took notice, and recognised that there’s a hard problem here—that’s cause for celebration.

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.