Henrik Warne on the --dry-run flag:

Early in the development process, when testing the incomplete application, I remembered that Subversion (the version control system after CVS, before Git) had a –dry-run option. Other linux commands have this option too. If a command is run with the argument –dry-run, the output will print what will happen when the command is run, but no changes will be made. This lets the user see what will happen if the command is run without the –dry-run argument.

I’ve added a --dry-run flag on scary destructive stuff I’m planning to run on prod. But not as often as I’ve wanted.

The downside is that the dryRun-flag pollutes the code a bit. In all the major phases, I need to check if the flag is set, and only print the action that will be taken, but not actually doing it.

This is one of the things that has become less of a downside with AI writing more code for us. AI helps us write code faster, but what especially entices me is having more breathing room to add affordances like this.

Short review of Sofia Coppola’s 2010 movie Somewhere. Unless I miss my mark, it’s the same movie as Lost in Translation?

RollerCoaster Tycoon, a classic game from 1999 is still worth dissecting for its performance to this day. First a quick primer on bit shifting (new to me—I’m used to high level languages!):

What the << operator does here [NewValue = OldValue << 2] is called bit shifting, meaning all the bits that store the value of the variable are shifted to the left, in this case by two positions, with the new digits being filled in with zeros. Since the number is stored in a binary system, every shift to the left means the number is doubled.

Since this is a lot faster than multiplication, Chris Sawyer decided to exploit this as much as possible:

The even more interesting point about those calculations, however, is how often the code is able to do this. Obviously, bit shifting can only be done for multiplications and divisions involving a power of two, like 2, 4, 8, 16, etc. The fact that it is done that often indicates that the in-game formulas were specifically designed to stick to those numbers wherever possible, which in most modern development workflows is basically an impossibility.

I do want to disagree with that last bit. Impossibility sounds too harsh. We can’t decide the requirements for stakeholders, but plenty of things aren’t as set in stone as they seem. It’s our job to nudge things in the right direction, so the result works with the grain of our programs.

I love digital tools that have some analog look or feel to them. (Speaking as an Excalidraw super user.) Going to have to find an excuse to use this beauty!

How to multiply your shipping cadence while using agents responsibly. Matthew Binshtok on the Vercel blog:

There is a fundamental difference between relying on AI and leveraging it.

• Relying means assuming that if the agent wrote it and the tests pass, it’s ready to ship. The author never builds a mental model of the change. The result is massive PRs full of hidden assumptions that are impossible to review because neither the author nor the reviewer has a clear picture of what the code actually does.
• Leveraging means using agents to iterate quickly while maintaining complete ownership of the output. You know exactly how the code behaves under load. You understand the associated risks. You’re comfortable owning them.

I’ve seen a lot of strong opinions about disclosing whether code in a PR was written by hand or generated by AI. I don’t really care. The author owns the code in the first place. The author and reviewer have a shared responsibility for what happens on production.

Putting your name on a pull request means “I have read this and I understand what it does.” If you have to re-read your own PR to explain how it might impact production, the engineering process has failed.

The litmus test is simple: would you be comfortable owning a production incident tied to this pull request?