Goodbye, and Thanks for All the Bikesheds

I’m not exactly sure but I think he’s implying the AI labs aren’t profitable on inference? And that once the bubble pops those models won’t be available anymore? Just my assumptions

> Ever heard of Meredith Whittaker?

The fact that you name one makes her very rare indeed.

A bit of an aside, but after someone introduced me to the notion of Reversible Decisions, it quickly became apparent to me that the solution to the bikeshed problem is to throw money at it before the roosters can start preening about which color the shed should be.

Decisions that are reversible should just go with the instinctive answer of whoever volunteers to work on it.

I've been in many meeting rooms where, because of the number and caliber of people in the room, we've blown $5000 worth of combined salary arguing about basically nothing. I've been in a few where that number was well over $10k.

If you're going to assign a relatively medium talent engineer to solve a problem, it's cheaper to let them solve it twice, maybe even three times, than it is to try to figure out what the right solution is before touching a keyboard. It helps them grow to give them that autonomy, and more importantly training your team out of reflexively reaching for optimization for every single feature saves gobs of money over time.

The interface for a piece of code matters to everyone. The internal implementation details mostly matter to the bus number on that code. If they're happy with it, that matters a lot. That can be overridden by the consequences of that design, but I've seen a couple cases where the bus number for a module wanted a solution with fewer consequences but the group wisdom wanted something flashier but also more brittle.

Even the article talks about this. The backdoor is when there’s no E2EE - he speaks of the “absolute right to privacy” which the proposed age verification solution wouldn’t breach in any way, so it’s actually the loss of encryption. It’s when a legal and technical framework are put in place to do age verification which can be switched to identity verification in a blink of an eye. It’s when cryptographically attested software is the only way to use the internet which even the author, as a suporter of the upsides, knows what it implies on the downside.

> — Day 1-2. Tried $tool out. Oh boy! We have some work to do.

> — Day 3-5. OK, there were a couple of solid bugs there, and a fair number of what were technically bugs, but not actually all that bad.

> — Week 2. I guess that was it?

There are a bunch of tools in the developer toolbox that some people never use, and the opposition use religiously. We are especially bad in this industry at turning things into a boolean where they should be a dial or a continuum. Something about that intro to Logic class either rots our brains or works as a filter to keep most of the philosophers out.

In sports there are drills one does a couple times a month instead of every day. You're trying to harden pathways in the brain to make certain reactions be more automatic, to correct subtle errors and suboptimal answers to problems. You don't do them all the time because they're expensive in some way, like time or danger.

I think this is an area where we miss a lot. I don't do TDD all the time. Maybe a week every couple of months. And it's a split between very hard tasks and very simple ones where I practice it. It's easier to work on first principles on a simple problem, but sometimes when you're stuck on a very difficult one, you have to go back to first principles anyway.

"Difficult" can be further broken down into several categories. 1) I don't know how to solve this, 2) the problem is straightforward but arduous and I don't know if I have the stamina for it, 3) I thought I solved it but it's not working.

TDD is a good way to get yourself into bottom up thinking and 'work the problem' by testing your assumptions one at a time. At the very least you have something to show for your work at the next standup even if the answer still eludes.

Similarly, a linter can be good while you're building up muscle memory for writing code the way the current team thinks it should be written. However, it can be a nightmare when you're trying to do exploratory development to fix a bug. I've landed PRs on two different FOSS projects to run the linter after the unit tests for this very reason. I don't fucking care if the code is Clean right now I only care if I've fixed the NPE that is crashing production. The PR is a problem for an hour from now. I need to make it work and then I can make it right.