This finding the Nebraska guy post dives quite deep into graph theory and algorithms, and I found it really interesting.

Product is the leadership I expected as a tech lead/principal

This is similar to why & how I moved into product, firstly the “ticket-chopping folks” (which I had somewhat been previously anyway) and then true product management.

Of course, 5 years later I was burnt out and hated my job and very grateful to move back to software engineering … but there were lots of other factors there.

When you see a package with 10,000 stars, you’re not looking at 10,000 developers who evaluated it and clicked a button. You’re looking at a number that could mean anything. Maybe it’s a beloved tool. Maybe it’s a marketing campaign. Maybe it’s a malware distribution front with a Stargazer Goblin account network behind it, it’s pretty much impossible to tell.

I have long argued that stars and download counts are untrustworthy metrics. Lots of good details in that post.

Optimism, on the other hand, is a toxin to be avoided. Optimism is a subgenre of fatalism, the belief that things will get better no matter what we do. It’s just the obverse of pessimism. Both are ways of denying human agency. To be an optimist is to be a passenger of history, along for the ride, with no hope of changing its course.

I very much disagree with this definition of optimism. Optimism is a belief that things will get better because most people will actually work for that. Basically, it’s faith (not necessarily in a higher power), which is oddly missing from the happiness, optimism, hope trilogy here.

In fact, I think he entirely swaps the definition of hope and optimism. I am not at all optimistic (in that I don’t believe people will rise up, or that the people with power will make things truly better) but I have hope (unfounded, not driven by people action) that I am wrong.

Another vibespiling experiment, this one MiniJinja from Rust to Go.

This changes some dynamics. I feel less like technology choices are constrained by ecosystem lock-in.

I haven’t seen this mentioned in other similar attempts, and I agree it’s an interesting change in dynamics. It’s interesting also in terms of hiring and how broad language experience should be (or not) within a team.

Once, having people port your code to other languages was something to take pride in. It was a sign of accomplishment — a project was “cool enough” that someone put time into making it available elsewhere. With agents, it doesn’t invoke the same feelings.

I’m still curious to see how this plays out. I have seen several people unhappy about this - for now, ones like Armin vibespiling his own work seems the safest path.

uv is fast because of what it doesn’t do, not because of what language it’s written in. The standards work of PEP 518, 517, 621, and 658 made fast package management possible. Dropping eggs, pip.conf, and permissive parsing made it achievable. Rust makes it a bit faster still.

How uv got so fast.

A very comprehensive guide to sandboxing, particularly for AI.

Large established cloud providers are also supreme blame absorbers. As noted, doing business with them is nearly risk free for almost all corporate workers. Reams of consultants stand ready to defend your choices. Every supplier is on board. It is the go-to choice. Even if AWS suffers a day long failure, EVERYONE experiences that failure, which provides for great cover.

Bert Hubert on another difference between what the big hyperscalers offer versus a simple ‘cloud’.

Interesting thoughts from Glyph on “the next big thing”.

The fact is, our lifetimes have been an extreme anomaly. Things like the Internet used to come along every thousand years or so, and while we might expect that the pace will stay a bit higher than that, it is not reasonable to expect that something new like “personal computers” or “the Internet” will arrive again.

This is very much counter to popular thinking, but it seems entirely feasible to me.

An excellent summary of AI in 2025 from Simon Willison.

One point that I’m unsure about is the potential end of MCP: I agree that for coding purposes it doesn’t make sense (if you have a service without a CLI tool, build a great CLI tool, not an MCP server, for it). However, I still wonder if there is use for non-coding purposes (I’ve been experimenting with this for opal3). I don’t trust AI running my browser (as Simon explains), so how else do I interact (as a non-coder) with a closed system? Maybe there should just be a .wellknown link with a skill, but I still need to help the agent authenticate somehow. But will people use “custom connectors” in Claude, and similar features in other agents?

But for me, this year was for AI what 2010 was for the cloud: the year when AI stopped being satellite, experimental tech and started being the mainstream, foundational technology. At least in the world of developer tools. It doesn’t mean there isn’t a bubble. Of COURSE there’s a fucking bubble. Cloud was a bubble. The internet was a bubble. Every massive new driver of innovation has come with its own frothy hype wave. But the existence of froth doesn’t disprove the existence of value.

Charity Majors on AI in 2025. This is much how I feel too.

Interesting post from Armin Ronacher on using Claude to do the Avent of Code, which I imagine was popular this year. The write-up, also by Claude, is less interesting because so much of it is just restating what was in the prompt, plus some awful anthropomorphism stuff.

A new, easy to use, very handy, tool from Simon Willison to make static HTML versions of Claude transcripts. I vibe-coded a GitHub action to host them on GitHub pages, rather than in a gist, for example, making beszel-k8s-operator.

Interesting how little has changed since this summary of AI use from roughly a year ago.

I feel this is an insightful look at the analysis gets done:

Finally, in most workplaces, incentive structures don’t exist for people to (a) reduce their workloads to such an extent that their role becomes vulnerable or (b) voluntarily accept more responsibility without also taking on more pay.

This day-2 operations post is a bit marketing heavy, but these are good suggestions:

Tip 1: Small Changes are the Best Changes Tip 2: Build, Then Follow, a Consistent Roll Out Sequence Tip 3: Ensure You Have One (Or Several) Canary Nodes Tip 5: Get Smarter About Configuration Management

Interesting insights into product engineering at Posthog. I liked:

why engineers are usually right – is they have the deepest understanding of what can be built. They understand the technical constraints, see patterns across features, and know exactly how to solve a problem.

And:

The PM, engineers and exec team then meet to discuss questions like: Are our 10 biggest customers happy users of the product? Do high ICP and non-ICP customers use the product differently? Why was churn high last month? Can we identify any reasons? Can we find leading indicators that predict long-term product usage? (e.g. Facebook’s 7 friends in 10 days) Where in the onboarding funnel do new users struggle?

I’m definitely happier being out of product, but posts like this remind me of the times when it worked well.

Interesting details on what Claude’s Plan Mode actually is.

An introduction to how Jubilant was designed by my manager, Ben Hoyt. I really like this approach, and copied it quite closely into another work project (ops.hookcmds).

A set of excellent questions at the end of this Python to JavaScript conversion by Simon Willison:

Does this library represent a legal violation of copyright of either the Rust library or the Python one? Even if this is legal, is it ethical to build a library in this way? Does this format of development hurt the open source ecosystem? Is it responsible to publish software libraries built in this way? How much better would this library be if an expert team hand crafted it over the course of several months?

Obviously, a lawyer (or court) needs to answer the first one (and potentially it differs by country). I don’t know what my answers to the other four are.

I’m also doing one of these conversions at the moment (with Claude Code), but it’s of a tool I maintain (for work) and not intended for outside use, so simpler.

Rules for modern life, that I entirely agree with (although tipping best practice varies by country). Two notes:

3/ Being good with names is a question of effort.

I’m sure there is some truth to this, but I do think some people are naturally good at this and others (like me) are not. I’d replace this with “Be tolerant if someone messes up or forgets your name”.

24/ Salary and rent are private matters (but be assured that most people feel one is too low and the other too high).

I think this is true, but I also feel society would be better if it was not.

Interesting reflections on life last year from Armin Ronacher.

I love “dare to commit”:

Life isn’t about sampling everything; it’s about making deliberate choices and committing to the ones that matter. You don’t need to date twenty people to find the right partner, nor do you need a network of hundred acquaintances to succeed. Similarly, you don’t need to work at ten different companies to build a meaningful career.

And on children:

You grow above yourself when all the sudden become fully responsible for another human being and you can’t opt out of it. It also invites you to reflect on yourself more and how you came to be the person that you are. I also don’t think it makes you any less ambitious, but it changes how you define success for yourself.

And his final note:

Whatever your journey may look like, I hope you find joy, purpose, and the courage to commit fully to it

A great summary of tips for writing a link blog from Simon Willison. I’m continually trying to move closer to his practice (other than the technology - I’m happy not running that myself, and would switch out my other site from WordPress before changing this away from micro.blog).

I’ve been remote working for 20 years (!) now, for companies that have had a range of approaches. Based on this post from Linear, they’re doing it pretty well. A lot (not the “how we work” section) is pretty similar to Canonical, who also have it mostly right (and at 10x the scale).

Good advice for reviewing documents.

Regarding this final aside:

II think the user experience around commenting on documents is fundamentally wrong in most document editors. … Ultimately, you want to collect all your comments into a bundle, then review that bundle for consistency and duplicates, and then submit that bundle as commentary, but editors don’t support that flow particularly well.

I’ve made this argument (and others!) against using Google Docs for this type of document and review before and have consistently lost the argument. What does have this flow? GitHub pull requests.

My previous email was sent to the Spam folder for at least Gmail, and from reading the email I am not sure why this would be the case. … Reliable communication technologies like RSS are the answer.

The subscription technology isn’t the issue here. The defining characteristic of email is that it’s open: anyone can add to your inbox if they have your address. With RSS, I have to explicitly allow new entries into my reader (a feed at a time). You can do that with email too: just add the sender to an allow list, and have that only work if the sender is verified (DMARC). Unfortunately, email client development stagnated and we don’t have good tooling for this.

RSS reader somewhat stagnated too, but seems to attract more indy love than email client development. Or more successful development, anyway.

(For what it’s worth, I do subscribe to his blog via RSS. My recommendation is NetNewsWire.)