I also find it annoying when Claude Code picks an old action version, but dependabot immediately opens a PR to fix it, so that seems as convenient as remembering to point it at something like this. It was more annoying when it used to do web searches to try to get the hash to pin to (which was always wrong), but these days I think there’s a baked in skill that knows how to use Git to get the right one.

I like “numbers you should know”, like this Python one or this latency one, but I feel you should have a sense of the difference here, and maybe some idea of the algorithmic complexity and CPU/memory trade-offs for some, but don’t need to actually know them. You can always check them, or look up pages like this.

(The Python one is a very nicely put together page, though.)

Interesting insights into managing Go dependency updates particularly in light of the recent Trivy issues.

First and most obvious, when we read to hit a goal rather than simply for pleasure, everybody reads as fast as possible to hike up their numbers.

I don’t find this to be true. If I wanted to bump my numbers, I would read short books. The goal encourages me to read rather than scroll TikTok or other less healthy ways to consume time.

More worrisome, when we read fast, we experience nothing. The book does not have a chance to burrow into our heart.

I don’t think this is true, either. I have read fast my entire life, and absolutely there have been books that burrowed into my heart.

If we’re gamifying our reading, we stop reading widely: we pick different versions of a story that we are guaranteed to like, and with that we lose a sense of well-roundedness, a sense of discovery and surprise.

Surprise, I disagree with this too. I read more widely now than I did in years past, and I track my reading now and didn’t in the past. I don’t believe there is any connection at all between these two things.

From What We Lose When We Gamify Reading - I’m not sure I would classify tracking reading and an annual goal as gamifying either.

None of them are what I would call evangelists; they are people who have felt reticent to adopt these tools, and still have some serious feelings about being complicit in the environmental cost and the politics around who’s building these tools and why. But now they’re using AI—Claude, mostly—to do the vast majority of their programming work.

👋 🙋

I don’t love Spotify, and I have issues with Wrapped, but this is an interesting insight into producing more than a billion AI generated reports.

I keep coming back to the trees. I’ve been maintaining Open Source projects for close to two decades now. The last startup I worked on, I spent 10 years at. That’s not because I’m particularly disciplined or virtuous. It’s because I or someone else, planted something, and then I kept showing up, and eventually the thing had roots that went deeper than my enthusiasm on any given day. That’s what time does! It turns some idea or plan into a commitment and a commitment into something that can shelter and grow other people.

A bit like a Mainland ad but for AI (and more thoughtful).

Clearly a bit biased, but good advice on feature flags that goes beyond Posthog.

I used a feature flags system like described here for something like a decade before moving to LaunchDarkly and it worked amazingly well. I’m not sure the move to LaunchDarkly actually paid off.

An interesting summary of expression end detection across a bunch of programming languages. Including Odin, which I have never heard of previously.

All of these lessons learned are ones I’ve seen before, but it’s a nice collection.

I particularly resonate with:

Admitting what you don’t know creates more safety than pretending you do.

and

Writing forces clarity. The fastest way to learn something better is to try teaching it.

An interesting use of nullcontext to have a parametrized test with valid and raising values.

An interesting categorisation of forks (towards the end of the post) from Monty of MySQL and MariaDB fame.

“Defense in Depth: A Practical Guide to Python Supply Chain Security”: an incredibly high quality post by someone with respectable credentials. Read the whole thing.

I like (a lot) webs of trust, but this human.json doesn’t seem like it will scale or give great information or really own the trust. I do like seeing example.com/~user style URLs, though, very nostalgic.

We need to expect to earn our keep. In the ZIRP era I think a lot of software devs lived in some world where they expected to make a lot of money in a way that was divorced from the realities of the business.

I feel there’s truth here, as much as I sympathise with those hit by change (and as much as it was painful when I was).

A depressing read on how ads have screwed up websites. I read almost everything either via RSS (NetNewsWire) or a read-later tool (Instapaper) so see almost none of this. The bit I hit most is the “CLS Disaster” on Goodreads, where I know now I need to wait when entering data because all the links I want will jump down the page after a giant ad loads at the top.

how come so many coders don’t just hate LLMs for stealing their work the way that most writers and photographers and musicians do? The answer boils down to three things:

Coders have long had a history of openly sharing code with each other, as part of an open source, collaborative culture that goes back for more than half a century. Tools for writing and creating code have almost always offered a certain degree of automation and reuse of work, so generating code doesn’t feel like as radical a departure from past practices. Software development is one of the fields with the least-advanced cultures around labor, as workers have almost no history of organizing, and many coders tend to side much more with management as they’ve been conditioned to think of themselves as “future founders” rather than being in solidarity with other workers.

Insightful comments on the likely impact of LLMs on dev work.

Handy suggestions for serving docs so that AI can get them more effectively. Unfortunately, with a ReadTheDocs site behind Cloudflare, I don’t think I can do any of this. Maybe some instructions to get the source files for specific sites, but they can’t be custom then.

Interesting information on the impact of current AI on employment, although from a very involved source. Somewhat terrifying that they have the data to do this, though.

“It’s like if the only way I knew how to make a hamburger bun was to carefully put every sesame seed by hand on the top only to stumble upon an 8 pack of buns for $4 at the grocery store after years of using tiny tweezers to put the seeds in exactly the right spot."

It doesn’t always feel like this, but it sure does sometimes. I’m sure there are people in the market for artisanal hand-crafted bun tops, and that it’s a great hobby for some, but it’s not going to hold up as a great career choice.

The level system (junior, mid, senior, staff) was never a development model. It was a compensation and expectations framework. It told you what someone should be able to do at each level. It said nothing about how they got there. But because the environment was producing growth on its own, the gap was easy to ignore. The labels tracked what was already happening, and everyone assumed the structure was the mechanism.

Interesting observations on the growth from junior to senior, and how AI changes that, or maybe for some managers doesn’t change it much at all.

“Never Send A Human To Do A Machine’s Job”. The first half is a great read on what the real benefit of code review is. And there there are some interesting thoughts on AI, which you can skip if you’re not into that, and still get much value from the post.

An interesting suggestion to start out by saying “first run the tests”. I’ll try to remember to give this a go a few times. It seems like it would be a bit annoying to do every single time. Although I guess an AGENTS.md could have it. It would put pressure on making running the tests much faster, because instead of being between the agent and getting the work done, it’s between me telling the agent what work to do.

This is very much a marketing post, but this:

Most code review tools start and end with the diff. They might expand to the file, or even the repository. But that’s not how the best reviewers think.

When a senior engineer reviews code, they’re drawing on years of institutional knowledge. They remember that Slack thread from six months ago about why the team chose this particular database pattern. They know that David on the platform team has strong opinions about error handling. They’ve internalized dozens of unwritten conventions that never made it into any style guide or lint.

is very true (it brings Chesterton’s Fence to mind) and not something that comes up in a lot of code review discussions.