Coffee on the Keyboard

A thought experiment: Imagine you have two computers sitting next to each other, about one foot apart, each displaying a clock.

I made a tool to learn more about the SPIFFE and Spire libraries and APIs.

I realize by saying this publicly I might be putting my own career and future opportunities at risk.

We've all been there: the project is nearly complete, there's a deadline, and someone comes to a status meeting with a problem.

At StaffPlus this week, I was talking with some other senior technology folks about the risks that come with the weight of our opinions ("never think out loud, people will think it's an actual plan") and the sense of pressure to get it right when talking…

Growth requires discomfort.

Sandi Metz famously said "duplication is far cheaper than the wrong abstraction," and my experience has been that following that advice has usually worked out well.

Writing code—no matter how much, how fast, or how challenging—is not the same thing as having impact on a business.

When we say "deeper in the stack" we usually mean a dependency, or a dependency's dependency, or...

Blame happens when we stop our investigation with operator error.

(Before I get started, a moment to appreciate this header image and whatever was the genesis of it.)

There's a genre of post I've seen on LinkedIn and the fediverse recently that goes something like "I worked with people in person again and forgot how great it felt!"

A couple weeks ago, the Wall Street Journal published 10-minute interview with Mira Murati, CTO of OpenAI, in which Murati said that their new "Sora" video generator model was trained on "publicly available or licensed data" (emphasis added by Ed Zitron).

This is a collection of some of the articles, blog posts, podcasts, etc, that I've read in the past couple of weeks.

My favorite term for the sort of engineering work we need to do to avoid things getting "too bad" is one I learned from Camille Fournier: "sustaining engineering."