Most people generate CLAUDE.md with /init at least at first, so it gets filled only with the superficial top level things that Claude already noticed during that first run. By this logic, shouldn't CLAUDE.md contain the exact opposite of what /init currently includes?

Devices like this usually come with an A-to-C cable in the box and that's a warning sign, but an even more twisted version of this is when they come with a C-to-C cable and a Type C charger that does not support PD. That's the only combination they tested, and that's your problem now.

I now carry enough adapter cables that I can deliberately take PD out of the equation just to work around these devices.

I appreciate that Framework has not only brought that back but expanded on it further, but they've done it at a very different time in the market. Now that maintainability and customizability does come at a compromise to at least one of cost, bulk, or performance. That's not only the case when compared to the Neo, as far as I know it's also the case at the high end compared to a MacBook Pro.

They've set out to do something that would be difficult in any case, but they're also doing it against Apple's advantages of vertical integration and economy of scale. I'm sure I'm not the only person that can deeply respect that while still not feeling any interest in buying any of their available products.

I get where you're coming from in principle, but I'm not sure to what audience this actually applies. If you just want a laptop that can run the software you use, both are adequate as tools. The Framework's greater flexibility only applies to making changes to the tool itself, which doesn't matter if you didn't need to change it to suit your purposes. (And I say that as someone who has built their own Linux & Windows PCs from parts since high school, because I know I'm not the target audience for a Neo)

It's like I consider my Dewalt power drill a very decent tool because it has exactly the modularity I need -- it even has interchangeable batteries -- and it wouldn't even occur to me to call it an outright appliance even if another power drill offered more customization for some niche use case. The Neo is an adequate tool for many people even if other tools do offer more customization or maintainability.

This would be a much stronger argument against using an iPad for productivity, because many people simply cannot run the software they need, or only at a significant expense to productivity and quality of life. I use iOS devices only as communication and media terminals, and even then I would struggle to call them appliances, they're still tools for their particular tasks.

Of course it was always understood that you could have bugs in C libraries and some of them may include memory unsafety, but the culture is very different when there's no explicit way to demarcate the parts of the code most deserving of scrutiny.

Don't get me started on how you need to move "blocking" work to separate thread pools, including any work that has the potential to take some CPU time, not even necessarily IO. I get it, but it's another significant papercut, and your tail latency can be destroyed if you missed even one CPU-bound algorithm.

These may have been the right choices for Rust specifically, but they impair quality of life way too much in the course of normal work. A few years ago, I had hope this would all trend down, but instead it seems to have asymptoted to a miserable plateau.

Take a look at `git rebase --interactive`.

If you've been monitoring properly, you buy yourself time before it becomes a problem as such, but in my experience most developers who don't anticipate load scaling also don't monitor properly.

I've seen a "senior software engineer with 20 years of industry experience" put code into production that ended up needing 30 minute timeouts for a HTTP response only 2 years after initial deployment. That is not a typo, 30 minutes. I had to take over and rewrite their "simple" code to stop the VP-level escalations our org received because of this engineering philosophy.

I get where he's coming from, but I've seen people get this very wrong in practice. They use an algorithm that's indeed faster for small n, which doesn't matter because anything was going to be fast enough for small n, meanwhile their algorithm is so slow for large n that it ends up becoming a production crisis just a year later. They prematurely optimized after all, but for an n that did not need optimization, while prematurely pessimizing for an n that ultimately did need optimization.