Reading List

The most recent articles from a list of feeds I subscribe to.

Impact, agency, and taste

If I were to share some thoughts on making a meaningful impact at work, Ben Kuhn’s post would be it. His essay had me nodding yes, yes!, and YES! throughout, and it’s written more eloquently than I ever could.

Don’t rely too much on permission or encouragement. […] instead of asking people for approval to go do something, you can just tell them what you intend to do (implicitly giving them space to object or course-correct if they feel strongly).

You can just do things.

Make success inevitable. There’s a huge difference between the following two operating modes:

  1. My goal is to ship this project by the end of the month, so I’m going to get people started working on it ASAP.
  2. My goal is to ship this project by the end of the month, so I’m going to list out everything that needs to get done by then, draw up a schedule working backwards from the ship date, make sure the critical path is short enough, make sure we have enough staffing to do anything, figure out what we’ll cut if the schedule slips, be honest about how much slop we need, track progress against the schedule and surface any slippage as soon as I see it, pull in people from elsewhere if I need them…

The hard part is being honest with yourself. I’ve often fallen into trap (1) because I’m afraid my plan will surface failure.

On taste:

I’ve noticed a lot of people underestimate their own taste, because they expect having good taste to feel like being very smart or competent or good at things. […] For this reason, the prompt I suggest here is: what does it seem like everyone else is mysteriously bad at?

Taste isn’t about being the best at something. It’s about slowly lifting the whole by leaving small things in better shape than you found them.

In Praise of –dry-run

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.

"Somewhere" (2010) review

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

The gold standard of optimization: A look under the hood of RollerCoaster Tycoon

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.

MarkerHighlight.js

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!

MarkerHighlight.js