kqr

I'd argue it's actually better to do 25 % at once and then not doing anything like it for ... decades, ideally, but years, realistically.

Spreading it out means employees spend some of their time with an ear to the ground rather than working, and teams have to deal with multiple restructurings, neither of which are good for well-being nor productivity.

I would assume it's the harness sending the model a notification toward the end. At least Claude Code is designed to attach reminders with tool call output as a way for the harness itself to steer the model slightly.

The momentum, I think, matters a lot more than the other two. Makefiles already allowed you to build layered things with caching. Artifact repositories have also long been a thing.

But the argument I used for advocating Docker in environments where people were not fans of it was that the Linux container had become the de facto standard unit of deployment. There is so much tooling written under that assumption, and if you want to use any of that tooling, you need to package your deployments as Linux containers, even if you want nothing to do with Docker otherwise. That's why it had so much momentum.

Then a fourth point I think you're missing is that the concepts used by Docker are relatively simple. Before I understood what Linux containers were, I used to think things like, "Why would I care about Docker when I can isolate my processes with Linux users, cgroups, namespaces, etc." What I didn't know at that time is that "Linux users, cgroups, namespaces, etc." is exactly the thing Docker was giving a friendly UI to.

If you could tell ahead of time which components would be unreliable, that would be a great idea. For the most part, we only discover the component was unreliable after it's caused trouble. Removing the component at that time gets you at best a very short-lived improvement to the system because it'll happen again and again with other components.

If the component removed is a human, the situation is worse. Then you're creating an incentive to hide mistakes and assign blame to others. This makes it even harder to improve the system properly, because then the information you need to improve the system no longer gets to you undistorted.

That's why we have to design systems that don't assume components are perfectly reliable, and ensure any human components that we're not out to get them, we're out to create an environment where they will find it hard to make mistakes.

IIRC this is also somewhat verified empirically. I think it was in Steve McConnell's I saw a plot of fault injection rate as a function of change size based on real data (probably collected in the '80s, but still!), and the number of bugs per line of code were by far highest in the 1–5 line change range.

This is the sort of thing that's difficult to argue economically for studying with proper randomisation and everything, but an observational study can be made on open source repositories (even in projects where the main contributors are on a corporate payroll) fairly easily with LLMs these days. I wish I had more time to pursue things like this...

Not only that, it's also one of the very few instances in history where the film adaptation rivals the original work. But the book is great too; Palahniuk does amazing things with language.

Eh. I'd rather we set up a system where we don't have to rely on people being 100 % perfect for it to work. I'd be much more interested in what went on simultaneously that caused the meta data to get dropped, rather than who happened to be the one to do it this one time.

I have been going back and forth between Luxi Mono (serif monospace fonts are rare but look great on high-resolution monitors) and Hack (like Helvetica, it has virtually no personality and thus fits well everywhere). Everything else I've seen has looked... weird or off somehow. But this is one of the first alternatives I'm entertaining the idea of trying.

My main concern is that the tall glyphs for less than < and greater than > will disambiguate badly with actual Unicode left 〈 and right angle brackets 〉.

Edit: I also realised just now the ASCII hyphen-minus - is quite long with this typeface, which makes it ambiguous with the longer dashes. (It looks freakin' great in pure ASCII environments, though!)

How do you ditch Claude Code without paying for API tokens? (Assuming from the way you phrased it that you still use Claude, only you didn't want the system prompts that came with Claude Code.)

Last I looked into it, using other harnesses with a subscription was a TOS violation that Anthropic seemed to take quite seriously (with automatic rate limiting etc.)