Weeknotes 28

Following radical candor and radical sensibleness, I propose a new thought technology: radical competency.

It can be summarised in three steps:

1. Think about a thing.
2. Say you’ll do something related to step 1.
3. Do the thing you said you’d do in step 2.

This is inspired by recent experience and by Maciej sharing Chelsea Troy’s “Reviewing Pull Requests”. While I’m not sure I agree about pushing commits to someone else’s branch, I agree with the goal of saving time and frustration by placing more burden on the reviewer.

In any exchange, you should be trying to reduce effort for the other party.

E and I watched “Star Wars: Episode IX - The Rise of Skywalker”. It was not good.

Following last week’s debugging adventures, I switched re2 from using Travis CI to GitHub Actions.

Most of my effort went into writing a new, custom GitHub Action called “re2 Test Action” which creates a consistent environment using Docker for running the re2 test suite against different versions of Ruby and the underlying re2 library.

It was a little tricky because the recommended way to setup Ruby versions with GitHub Actions only supports Ruby 2.4, 2.5, 2.6 and 2.7. However, the recently released RubyGems.org stats shows that the most popular Ruby version is Ruby 2.3 (and over 7% of people still use Ruby 2.1).

I’m attempting to get a more detailed breakdown of older Ruby versions as I’d love to know how many people are still using long end-of-lifed versions.

People have often been surprised, confused and occasionally frustrated that I support Ruby 1.8 in my libraries such as re2, Fieldhand and Embiggen. Having wasted so much time in my career struggling to upgrade dependencies that have, in turn, caused other breakages, I strongly believe libraries should go out of their way to be as compatible and frictionless as possible for the user to use. I never want one of my libraries to cause you incidental issues because I made a change internally.

While Mike Perham called for us to “Kill Your Dependencies”, I agree more with James Coglan who talked about this in Why Are Computers’ “Episode 1: A Fairly Deep Yak Shave”:

The thing that most concerns me is stuff that gets changed because someone thought that the new way is how it should’ve been done in the first place and it’s obviously better, but it doesn’t give any real new capabilities or power and doesn’t really fix any mistakes, and it breaks their existing software.

To me the canonical example of that is the Ruby 1.9 hash syntax, which a lot of people are like “oh, it’s obviously better”, but it doesn’t let you write programs that you couldn’t write before, it doesn’t fix any mistakes that anyone was making before, and it means that if someone uses that syntax, that program now won’t run on an older thing. It’s purely an aesthetic change. The aesthetics of code are important, and it’s important to have stuff that’s readable, but if you have a thing that’s already been shipped, making those tiny little fussy aesthetic changes to it, to me, never seems really worth it.

Never one to let a bank holiday weekend go to waste, I spent a large portion of yesterday on administrivia mostly informed by Martin Lewis’ “Money Saving Expert”.

On a bittersweet note, we finished “The Great Pottery Throw Down”. I am attempting to fill the hole it has left in my life by encouraging C to watch “Hey Duggee” instead.