We’re going to have a retrospective next week: in that meeting, I will be helpful. There are things we could do as a software development team to limit our risk to production incidents.

Right now, I’m not going to be helpful. Right now, I’m mad. And if you’re mad, you should try and understand why.

The Setup

The user selects a number from a dropdown; my code does stuff depending on what the number is.

The user can also decline to pick a number. (Any developers reading this are now suspicious.)

For some reason, my code doesn’t receive numbers: it receives strings, that have numbers in them. Like so:

"1", "4", "", "7", "", "13"

This isn’t great, but the web is a pile of hacks.

You can see that sometimes, we get empty strings, to represent “the user didn’t pick a number”. (The developers reading this are now concerned.)

When writing the code, I realised these values were strings, and asked the computer to turn them into numbers.

The Problem

Specifically, I called the Ruby function to_i, which means “to integer”. Integer is just a fancy name for a number that isn’t a fraction or decimal.

This function makes a promise. You have a string; you want it to be a number. I (the function) will receive a string and give you a number.

But what to do when the string isn’t obviously a number? How should we respond to “”, or “sdghiwqruhgqw”, or “th1s is not a numb3r”?

Clearly (!), we can’t allow all strings to become numbers. “” or “sdghiwqruhgqw” simply aren’t numbers, and there’s no way to decide what number they should become. We could pick a random number, but that would make the code behave randomly, which nobody wants. To any non-developers reading, this is obvious.

For the developers: if you’re asked to turn a string into a number, and what the number should be isn’t obvious, you should throw an exception. The program should crash. It should be as clear as possible, as early as possible, that the person who asked for that string to become a number is doing something wrong.

The people who wrote the to_i function in Ruby disagree. They think “” and “sdghiwqruhgqw” should become 0.

The Payoff

So “” becomes 0. Because the to_i function didn’t crash, everything seemed to work great from my end. My code was reviewed. It was deployed to a staging version of the website, and the relevant pages were tested. All fine, just like Ruby said it was.

Until someone tried to do anything with that tricksy 0 value. The value was never supposed to be 0, so it made the website fall over. This didn’t happen until real users got at it.

When behaviour in your code is undefined, please, make bad things happen.

You may think: this describes all software! When I try to log in to an online service, it makes a decision about whether to log me in or not based on my provided credentials.

In one sense, this is correct. A common metaphor is to say that our login-bot is given instructions (code) about how to process a login request, which allows it to make a decision.

But consider: if the login-bot makes logs me in to an account that isn’t mine, is the login-bot at fault? No, of course not. The software engineer who wrote the instructions is at fault. That software engineer thought up the login instructions and made all the decisions about their implementation.

Now, let’s switch out our login-bot for an LLM. I give the LLM some credentials, and it logs me in to an account that isn’t mine. Who is at fault now?

Clearly, the LLM has made a decision to log me in, independent of any human instruction. I could make the same request again and it might do something else.

Is the LLM at fault? Perhaps this could be sensible if it were alive, but it is not. It is not part of our community or our society, so judging it for its decisions simply serves no sense - what would it achieve?

Maybe the person who trained the LLM is at fault. Training gave the bot its ability to make decisions, and the matrix by which it does so. This feels analogous to the login-bot’s instructions.

But the person who did the training had no way of knowing this would be the outcome: they could not shape all possible outcomes of the LLM’s decisions. They cannot be at fault for an outcome they could never have predicted.

No, the person at fault is the person who decided to use an LLM for this purpose in the first place. The blame lies with leadership.

As we scramble to cram LLMs into everything, from government to finance to healthcare, I wonder if they’ll accept it.

(Spoiler alert: they won’t.)

Equally often though, there are whole chapters to wade through that are sufferable yet forgettable. So I thought I might save people some time by sharing the main thing I got from the book:

More PRs More Gooder

If you’re going to do a refactor (or a tidy, which the book tries to distinguish from refactors), ship the refactor in a separate commit (and/or PR) to the actual behaviour change you’re making. This advice is ambivalent to whether you do the refactor before or after the behaviour change.

This has a big advantage in clarity of purpose, for you and anyone reviewing the code.

The downside to this is increased review and testing burden, due to the fixed costs of both. It was discussing this point that the book crystallised something for me:

If code gets reviewed rapidly, then you’re encouraged to create more, smaller PRs. These more-focused PTs encourage even more rapid reviews. Equally, this reinforcing loop can run backward, with slow reviews encouraging larger PRs, further slowing future reviews.

This reframed the entire trade-off discussion for me. You aren’t just making a decision about code style, you’re making a decision about your team culture. Even if your team is just you, it still has a culture; and fom this position, it’s obvious that you should foster a culture than supports clarity and speed.

The Bude Tunnel is a dull plastic tunnel that connects a Sainsbury’s car park to the actual building, to stop people getting rained on. (Sainsbury’s is a supermarket chain the UK.) It happens to be in a popular seaside/surfer town called Bude in Cornwall.

In all it's glory

If you read the reviews, you’ll find out that people really, really like this tunnel.

“The Bude Tunnel transcended not only my expectations of this pretty Cornish town, but of all future tunnels I may have the privilege to pass through for the rest of my days.”

“When travelling through The Tunnel one is hit with the unmistakable, yet ineffable, feeling of fulfilment and serenity that I have yet to have experienced in my 22 years on this planet.”

“The 8th wonder of the world?”

It’s hilarious. My partner and I discovered the tunnel years ago, and for the better part of our relationship, we have on disparate rainy evenings loaded up the reviews and laughed together. (Sometimes this devolves into laughing at the names of Cornish towns, about 60% of which are funny just to say.)

Last week though, we went on a trip together through that part of England. The tunnel was not the driving force of the trip. We had plenty of places that “deserved” to be seen on the itinerary: Stonehenge, the Eden Project, the Minack Theatre. And those places were not especially close to Bude. But when we’ve laughed at the thing for years, how could we not?

And that’s a bit weird, isn’t it? If we’d discovered the tunnel while researching the trip, the idea of visiting would’ve been just as funny, but we wouldn’t have gone out of our way to visit. Something about the long period of time knowing about the tunnel turned it into something we had to see. Our shared experience, and the whimsy of the internet, made an event from nothing.

And the point I’m building to is that it was an event. Reaching the Bude Tunnel, after knowing about it for so long, felt like the end a pilgrimage. To reach for a metaphor only some people will be able to get (sorry): when you first find yourself among Americans, and they’re talking like all human beings do, with false starts and all at once and no laugh tracks, it can feel weird. A thing that’s lived pressed and varnished in your mind suddenly comes flailing into the real, 3D world, full of experiences. It’s in you peripheral vision, and it’s under your feet.

The Bude Tunnel was just a silly internet joke, but my mind made it into an experience with value. For someone privileged enough for existential problems about meaning and purpose and achievement to be among my primary concerns, that was… kinda shocking. And nice.

Life really is what you make it. Go make some experiences.

My theme for this year is Frontier, and it’s shaping up to be an interesting one. Let me tell you what it means.

When I choose my themes, I usually choose my word first, and let meaning follow. Frontier felt right; in my experience, that’s good enough. Meaning will find you. Here are the ones that have found me so far:

I - Expanding Radius

At first blush, Frontier means to be at the edge, to push into things foreign or unknown. The new coffee shop I’m sat in is a great example of this, and so is this blog post. More travel is so obvious it’s boring.

There’s something more to the concept of your personal radius though, beyond what coffee shops you frequent or what cities you’ve been to. We can say your radius is the set of actions you can perform without discovering. Discovering what? New places, new patterns, new people; anything.

Discovery is not the same as learning, in the same way that reading about Peru is not the same thing as going to Peru. You can discover by reading, but you can only learn, rather than discover, the direct contents of the book. Rather, a book can help you discover things about yourself or your life that you previously hadn’t considered: things that were outside your radius.

II - Self Sufficiency

On the Frontier, you need to provide for yourself. Pushing into the unknown requires a more conservative attitude than staying put, where you have support networks to help you if you fail.

This has an important direct meaning for me, after burning out at the end of last year to finish my latest iOS app, Thought Path (wink wink, nudge nudge). I pushed too far, and cut myself off from my support systems.

Another meaning has grown out of self sufficiency in my mind, though, where our metaphor falls down. This is the least defined of my Frontier meanings, and maybe the most important.

III - The Dance

How do you achieve success and not burn out?

There’s a certain amount of swagger to all people who can do this. These people trust in their own abilities and opinions, and are masters of the old maxim that people make their own history, but they do not make it on terms of their choosing. They can cultivate their environment to match their desires just as easily as they modify their desires to meet the demands of the world around them.

This dance, of pushing and pulling, of changing the world and changing yourself, seems to be the key.

Aiming straight at your long term goals is doomed to fail: you’ll burn out before you get there. Instead, you want to zig-zag: get the lay of the land; establish forward bases; never make any step you aren’t comfortable making, but always be moving in the right direction.

It can’t go unsaid that for a lot of people, perhaps even most such people, this attitude comes from a background of privilege. The environment may be unfavourable to you; regardless, you must cultivate the confidence to change it, ever so slightly, to be more favourable.

That’s the dance of life.

Future posts to this blog will probably be less about me, and more my takes on things out in the world. (Hey, that’s on-theme!) This was just to test the RSS feed - and to say hi :)

Which reminds me, you can subscribe to all future posts with RSS!