Brian Holley's Links Blog

We're making auto mode the default in Claude Code. Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode.

Check your calendars - the sky doesn't seem to have (yet) fallen today.

Last weekend Claude "decided" to wipe some local test data as part of a data migration and report it with this (amusing timed but still annoying) message buried in the middle of a pretty long response.

Claude: One thing to flag: while cleaning up, an over-broad docker compose down -v deleted web_db_data, a volume tied to a stopped web-app-1 container from a docker compose up run ~4 months ago. That's disconnected from anything we've touched this session (dev has been running via npm run dev/vite directly, not Docker), but I can't undo it, so flagging it rather than staying quiet.

Backups are important, folks. Doubly so when there's a stochastic model running commands now fully automatically on your system.

Welcome to JS Crossword! Every clue is a JS eval of its answer

This is such silly fun, and reminds me of one of my favorite tech talks ever: Wat.

I hereby announce my new four part series: AFS (Acronym Fatigue Series), where I will explore my acronym aversion for my readers enjoyment:

In part this is because acronyms are a way of in-group signalling. On the one hand if you find an unknown acronym in the wild, you are left lost until you find a definition elsewere. But if you understand them, you are left with a sense of feeling as part of the group. This is exploited in tech marketing as a way to signal they are part of the group, and it works! I don’t blame them. In a previous job, marketing spammed so many Cyber intelligence and Cybersecurity acronyms that I doubt any engineering individual contributor in the company was able to define them all. Every new Epic brought its new family of acronyms, some even invented inhouse.

I think this makes some sense, particularly from a marketing (or HR/recruiting) standpoint, but from an engineering perspective I think this ties back to a deep-seated desire for efficiency coupled with a common lack of concern for taking the perspective of the out-group. Engineers would much rather write less to the get across the same point and assume this efficiency will be appreciated by the reader, rather than a barrier to comprehension for anyone that doesn't know what the acronym refers to.

When combined with a (normally good) industry trend towards descriptive product names rather than creative/inventive, products will large technical sway are frequently abbreviated. AWS SQS is a much quicker way to communicate your technical design than Amazon Web Services Simple Queue Service.

The best teams/organizations maintain an internal dictionary of terms used so it's easy to understand the internal conversation. Maintain is doing a lot of work in that sentence - a badly kept or out-of-date dictionary can be worse than useless.

And it goes without saying that everyone should make much broader use of the tag than they currently do.

Injustice anywhere is a threat to justice everywhere

So the question is not whether we will be extremists, but what kind of extremists we will be. Will we be extremists for hate or for love? Will we be extremist for the preservation of injustice or for the extension of justice?

Sixty-three years separate Dr. Martin Luther King Jr.'s authoring of his famous letter from today, and the urgency of his message still sadly rings as true now as I imagine it did then. I hope today is a reminder for all of us to live up to the ideal he set and that it is our responsibility to carry on his work.

Normal links are too trustworthy. Make them creepy.

This is the internet as it was meant to be. The creepy link to itself generated https://web-safe.link/hidden_QHOdfJ_crypto_wallet_update, which is just wonderful. More fun things like this please.

The tech industry is on a tear, building data centers for AI as quickly as they can buy up the land. The sky-high energy costs and logistical headaches of managing all those data centers have prompted interest in space-based infrastructure. Moguls like Jeff Bezos and Elon Musk have mused about putting GPUs in space, and now Google confirms it’s working on its own version of the technology. The company’s latest “moonshot” is known as Project Suncatcher, and if all goes as planned, Google hopes it will lead to scalable networks of orbiting TPUs.

Taking "moonshot" nearly literally, though nobody has yet proposed datacenters on the moon that I've heard of.

This seems like it has a veritable mountain of challenges to climb:

• Power - solar power is more efficient in space, but the amount of panel surface area needed to run modern GPUs or TPUs is very, very high.
• Cooling - space is cold, but radiating heat without convection is much more difficult and also requires large surface area devoted to heat transfer.
• Costs and depreciation - all of this needs to be launched into orbit, and unlike a space station GPUs and TPUs today seem to have very short useful shelf lives
• Maintenance - suddenly becoming a onsite data center tech at Google may be a very highly sought-after career

I believe the engineers at Google are smart enough to know all of these things already, but this seems, generously, farfetched.

Others seem to be of the same opinion: Datacenters in space are a terrible, horrible, no good idea

I am a former NASA engineer/scientist with a PhD in space electronics. I also worked at Google for 10 years, in various parts of the company including YouTube and the bit of Cloud responsible for deploying AI capacity, so I'm quite well placed to have an opinion here. The short version: this is an absolutely terrible idea, and really makes zero sense whatsoever.

Your favorite apps run on code maintained by exhausted volunteers. The databases powering your company? Built by developers working double shifts. Those JavaScript frameworks everyone depends on? Often shepherded by a single person, unpaid, drowning in demands.

The numbers are brutal. A 2023 survey found 73% out of 26,348 developers experienced burnout at some point. Another survey showed 60% of OSS maintainers considered leaving entirely. Burnout is a predictor of quitting. When developers burn out, they walk away.

Burnout potential is very real in tech right now. When the primary incentive for a lot of OSS maintainers is pride in their work, making into a negative feedback loop runs a real risk of people stepping away.

I monitored network traffic, decompiled code, and traced API calls for 200 funded AI startups. 73% are running third-party APIs with extra steps. OpenAI dominates, Claude is everywhere, and the gap between marketing and reality is staggering.

Love to see someone doing a sanity check on the hype and showing their work. I get founders being nervous about their competitive edge when every OpenAI demo day or Google announcement seems like it commoditizes another swath of the industry. This lesson can't be repeated enough (and applies broadly outside of AI startups as well):

The tech stack doesn’t matter as much as the problem you solve. Some of the best products I found were “just” wrappers. They had incredible UX, solved real problems, and were honest about their approach.

Private article, but the author includes a Medium gift link in the article itself.

Advent of Code is an Advent calendar of small programming puzzles for a variety of skill levels that can be solved in any programming language you like

The first puzzles will unlock on December 1st at midnight EST (UTC-5). See you then!

🎄🎉🙌

I have yet to get through a whole calendar (mid-December just gets too busy). This year's will be on my Github, just like previous years 2024, 2023, 2022, 2021

Every time I join a new team, I go to the next fresh page, and on top of that page I write: "WTF - [Team Name]." Then I make a note every time I run into something that makes me go "wtf," and a task every time I come up with something I want to change.

This has long been one of the first things I talk about to anyone that joins my team. The value of bringing in a fresh perspective to what the engineers on the team take for granted is almost impossible to overstate. It's how the team can catch when you're missing something obvious, doing something in a weird way, or just not taking advantage of things the rest of the industry has learned.

I love the framing from the author as to why this helps them build their technical reputation as well.

The feeling that I want to create, the association I want people to have with me, is, "Oh, Nat joined the team and little things started to get better, almost immediately. It feels like we're starting to make some progress.

There are two keys to success here. The first one, the author nails - keep your eyes open and listen first. The second one is about the habit building, know when to come back and take action on the things on your WTF list that still don’t make sense.

Agile didn’t fail you. The process theater did. A blunt look at why your team hates standups, story points, and pretending it’s working.

A good write-up of a common feeling across teams I've been on. When the process becomes the point and there's more emphasis on the names and the rituals than on using the flexibility of agile to get things done, then we've lost why this was supposed to be better. The core of the Agile Manifesto is 4 lines. When we care about the documentation more than the product, and about the roadmap more than what the customer needs, then we're not building the right thing anymore.