Notes

The longest arguments in code review are about names. The compiler will check the logic. Nobody checks the name, even though the name decides what a thing counts as everywhere downstream.

"Temporary" is the most durable word in a codebase.

A ban has an author you can argue with. A default has none: nothing was forbidden, it was just made easier this way, and the awkward option never gets reached.

In corporate speech the word "just" almost always sits where responsibility is hidden. "We just connect people", "it's just a tool", and the question closes before it is asked.

A dashboard gives a feeling of control over what has already happened. We treat the graphs as a steering wheel, but they are a rear-view mirror.

"App update" is the quietest way to change the rules. A law has an effective date and a text you can contest. A release has a changelog nobody opened.

We call it technical debt, but the interest is usually paid by someone other than the borrower. By the time the bill comes due the authors have left the team, and the decision still runs in their name.

The daily standup is rarely about synchronisation. More often it is a ritual where everyone confirms out loud that they produced something yesterday. Hence the awkwardness on days when you were thinking instead of shipping.

"Work has become flexible" almost always means they handed the flexibility to the worker and kept the risk for themselves.

Good architecture and good criticism make the same move: they turn the implicit into something explicit, so that it can finally be argued with.

Every layer of abstraction frees someone and blinds someone. An ORM saves you from SQL, and from understanding what a query does, until it takes production down.

"Nobody's bothering you" is how we now describe both freedom and loneliness. Working remotely, it is the same sentence.

A postmortem teaches you to look for the cause in how the system is built and not to look for someone to blame. That is right and humane. Sometimes it is also a convenient way not to ask why the system was built that way.

An A/B test honestly answers which option gets more clicks. It stays quiet on whether the thing was worth showing at all. You cannot roll the second question out to one percent, so it usually does not get asked.

I started a book about how to stop optimising everything. I am reading it on a timer, to finish before the weekend.

A commit history is more honest than any story told about a project afterwards: it was written before anyone knew what would end up in the slide deck.