My friend Steve stayed over for a couple of days this week, which was good fun. The days ended up being longer than anticipated, with a bit too little sleep as a result. I really need my eight hours a night, it turns out. (The lack of sleep is a bit of a theme.)

---

Despite having used Git for many years now, I bumped into an entirely new problem with it earlier this week.

It turns out that if you have a branch with a certain name (say fix), then you cannot have any other branch starting with that name followed by a slash. Take a look:

% git checkout -b fix
% git checkout -b fix/bug-123

The error message that you get it as follows:

fatal: cannot lock ref 'refs/heads/fix/bug-123': 'refs/heads/fix' exists; cannot create 'refs/heads/fix/bug-123'

That is a terrible error message. I had to browse Stack Overflow for quite a while until I figured out what was going on.

At work, the branch naming convention is <type>/<description>, with type being fix or feature or so, and the description being the usual branch name. This is fine — at least until someone creates a branch named fix, preventing anyone else from creating any bug-fix branches.

---

I’ve been thinking about the use of approval gates in software engineering again, following a conversation I had with Tom Stuart. Behold my mostly unrefined thoughts below.

At most companies, I’ve observed that the process for getting a change into production consists of the following approval gates (all mandatory):

1. Code review
2. Manual acceptance test
3. Manual regression test

There are plenty of variations on this, but in essence this is what most engineering teams use. The idea is that by having lots of reviews, the chance of introducing bugs in production gets lowered.

This isn’t quite true, though. Code reviews are not an effective way of finding bugs. Acceptance testing and regression testing can help, but if you want to do that for every deploy, you’ll end up with a time-to-production that is days or even weeks long. Also, this will soak up so much time that could have been used in other ways.

En­gi­neer­ing teams are so focused on preventing defects in production that they mostly ignore recovering from defects. The latter is important too, because the impact of defects is a factor of the following:

• The number of defects
• The time to recover from defects
• The severity of the defects

By putting a focus only on decreasing the number of defects, the time to recover goes up (because the time it takes to get something in production is so high), and the severity of the defects goes up as well (because deployments are done in large batches).

When the process for getting things in production has so many approval gates, deployments are done in large batches, presumably to save time. Doing the process for every single changeset could easily take up an entire engineer’s worth of time.

I’ve witnessed, first-hand, defects that take days (instead of hours or minutes) to resolve, because the process of getting stuff to production is so cumbersome.

In my mind, it’s better to have five defects that each take an hour to resolve, rather than one defect that takes days to resolve. Not only is the total impact of the defect lower, it frees up time for engineers to work on other, more useful things.

Increasing the time to production by adding more approval gates is counterproductive, as the time to recover goes up even more and the severity of the defects increases. When an engineering team decides that each changeset requires two mandatory code reviews, for example, I know things are going from bad to worse.

Additionally, being able to ship code fast encourages keeping the codebase well-factored, because refactorings will also be shipped quickly and therefore not cause issues like merge conflicts down the line. In my experience, if it is cumbersome to get changes in production, engineers will tend not to bother with refactoring the codebase. A well-factored codebase is a desirably healthy codebase, where test coverage is high and changes are unlikely to create new defects.

---

In one corner of my apartment, I have a fruit fly infestation. In the opposite corner of my apartment, I have a spider. The spider is not helping. Yummies are over on the other side, my friend.

---

Entertainment:

• On Tuesday, with friends I attended Strange Foreign Bodies, a contemporary dance production. I thought it was very good — and typically, I’m no fan of anything calling itself “modern” or “contemporary”. I had a strong emotional reaction to it, and so I am very happy to have attended.

• I’m about halfway through Return to Monkey Island. It’s very good.

• I got my copy of The Excavation of Hob’s Barrow, but haven’t played it yet. Anything published by Wadjet Eye Games is worth it, in my book.

• I finished Bosch season 2. It was definitely better than season 1.

• There’s a new episode of The Rings of Power out, though I’m less and less inclined to watch it. Maybe I’ll leave it until the season is over, and then binge-watch it?

• I’m about halfway through Halo 2. Pew pew, says my plasma gun.

---

Links:

• Contrepreneurs: The Mikkelsen Twins (Dan Olson): Click This Link For An Unmissable Business Opportunity. Dan Olson’s videos are gold, and this one is no exception. I’ll definitely rewatch some time soon.

• OLD NORSE IN ENGLISH: The words the Vikings left behind (RobWords): I’m a sucker for language videos, and RobWords does them well.

• There Used To Be An Island Here (Joe Scott)

• The Music Theory of CBAT (the reddit guy song) (Adam Neely)

• The Alt-Right Playbook: The Cost of Doing Business (Ian Danskin)

• Which fonts to use for your charts and tables (Lisa Charlotte Muth): Good design advice, and I quite like the use of plentiful real-world examples.

• agave: succulent monospaced programming font: I saw this font in use on a coworker’s screen and just had to interrupt and ask what that font was. I like its playfulness, despite being derived from two mathematical patterns: the power of two and the golden ratio. More details on the construction here.

• The Appeal of Monorepo (Luca Pette): Polyrepos create such a waste of time. At work, I’ve been thinking about how to move towards a monorepo, and this article has given me some good arguments that I can use to convince people.

• A Better Way to Sort Ruby Objects: How our Put gem makes sorting by multiple conditions easy (Justin Searls): Ooh, this approach makes a lot of sense to me.

• Supertag: I’ve been interested in tag-based filesystems (as opposed to hierarchical filesystems), and maybe I need to give this a go. But ehh… the fear of data loss is absolutely going to prevent me from trying it out, is it not?