Priscilla Page:

Finally finished this long-gestating essay about Highlander. Obviously, there will be spoilers ahead. Since everyone loves talking about the mismatched accents and there was no place in the essay to insert this information seamlessly, I wanted to mention that no one involved in the production seemed to give a shit. They weren’t exactly aiming for realism. Although Christopher Lambert’s complete inability to speak English was shocking to the filmmakers — they didn’t meet him until after they cast him — but everyone had fun with it.

This was a fun read. I loved Highlander as a kid.

Ben Khun:

In a company like Anthropic, excellent project management is an extremely high-leverage skill, and not just during crises: our work has tons of moving parts with complex, non-obvious interdependencies and hard schedule constraints, which means organizing them is a huge job, and can save weeks of delays if done right. Although a lot of the examples here come from crisis projects, most of the principles here are also the way I try to run any project, just more-so.

Some practical advice on supporting AI agents from Diwank Tomer.

Two things that stood out to me:

1. Asking the AI to embed bits of context in comments for itself so it can reconstitute context on previous decisions.
2. Making the tests purely for humans as a way to give the AI more rope to make changes.

Casey Handmer:

A model I’ve long been interested in is the Corporation as a stand in for AGI. We need some non-human autonomous legal and economic entity. A corporation is just that. The Fortune 500 are already non-human super-intelligence. They operate 24/7/365 according to inscrutable internal logic, routinely execute feats of production unthinkable for any human or other biological organism, often outlive humans, can exist in multiple places at once, etc etc.

James Stanier:

The key is that you engage with your daily activities mindfully in a way that keeps your weekly update in mind. What I mean by this is that you are always on the lookout for:

• Direct experiences that you have had that would be valuable to share with the team. This could be anything from conversations with customers to shareable summaries of closed-door meetings such as executive reviews.
• Events that can be celebrated, such as a big project shipping, a long-standing bug being resolved, or performance improvements that have been rolled out.
• Things that could be improved, such as an incident that happened, an inefficient process that is causing friction, or data that highlights a problem that needs to be fixed (e.g. a drop in performance or an unexpected increase in infrastructure costs).
• Events that are happening in the near future that you want to remind people about.

Vojtěch Rylko and Werner Jainek:

Our legacy Things Cloud service was built on Python 2 and Google App Engine. While it was stable, it suffered from a growing list of limitations. In particular, slow response times impacted the user experience, high memory usage drove up infrastructure costs, and Python’s lack of static typing made every change risky. For our push notification system to be fast, we even had to develop a custom C-based service. As these issues accumulated and several deprecations loomed, we realized we needed a change.

They chose to rewrite using Swift on the server.

Jason Yip:

Good relationships facilitate future support and creates advocates. Being able to get something done is not just about your individual capability but also about your influence with the stakeholders and teams that you depend on.

A replication focused storage engine.

An englightening read.

Csaba Okrona:

“There is no right decision. There’s just the decision you make and how well you execute it.”

I’ve had very similar experiences and see others struggle with this.

I agree with the suggestion to “Treat decisions as experiments, not solutions”.

Folks often want to know the cost of implementing an idea.

Estimating that cost is work too and we need to surface that cost.

Love that Fuji decided to jam that 100S sensor into a rangefinder form factor.

Simon Willison:

Using LLMs to write code is difficult and unintuitive. It takes significant effort to figure out the sharp and soft edges of using them in this way, and there’s precious little guidance to help people figure out how best to apply them.

If someone tells you that coding with LLMs is easy they are (probably unintentionally) misleading you. They may well have stumbled on to patterns that work, but those patterns do not come naturally to everyone.

I’ve been getting great results out of LLMs for code for over two years now. Here’s my attempt at transferring some of that experience and intuition to you.

Some nice tips in this.

David A. Patterson:

I started my career at Hughes Aircraft in 1972 while working on my Ph.D. at the University of California, Los Angeles (UCLA). After designing airborne computers for four years, I graduated and then taught and did systems research at UC Berkeley for the next 40. Since 2016, I’ve helped Google with hardware that accelerates artificial intelligence (AI).

At the end of my technical talks, I often share my life story and what I’ve learned from my half-century in computing. I recently was encouraged to share my reflections with a wider audience, so I’ve captured them here as 16 people-focused and career-focused life lessons.