I’ve been seeing a lot of this type of sentiment about React recently…

By my reckoning, if you’ve maintained a React codebase for the past decade, you’ve re-written your application at least three times and possibly four. […]

By choosing React, we’ve signed up for a lot of unplanned work. Think of the value we could have produced for our users and company if we weren’t subject to the whims of whatever the cool kids were doing over in React.

This is such a good point about music discovery and the abundance of choice:

Before Spotify, when presented with a new album, we would ask: why listen to this? After Spotify, we asked: why not?

I also like this sentiment:

On one level it’s impressive that Spotify can perfectly capture my musical taste in a series of data points, and regurgitate it to me in a series of weekly playlists. But as good as it has gotten, I can’t remember the last time it pointed me to something I never expected I would like, but ultimately fell totally in love with.

For that you needed someone who could go beyond the data to tell you the story: of the artist, of the genre, of the music they made. For that you needed criticism.

I’ve definitely seen this too! How ✨ became the unofficial AI emoji:

In the relatively short history of emoji, sparkles have been used to express excitement and magic, said Jane Solomon, the senior emoji lexicographer at the emoji reference site Emojipedia. Branding new AI products with the ✨ emoji suggests that these tools are exciting and magical, which might encourage more people to test out the technology. “It can seem like magic if you don’t understand how it works,” Solomon said.

My work at Jeli so far has given me a new lens on “incidents”—both in the software world and beyond—that I didn’t have before. These “failures” are everywhere around us. But are they really failures? Or are they ways for us to learn more about the systems we work within, and how to improve them? I think it’s the latter, and My $500M Mars Rover Mistake by Chris Lewicki is another story that showcases that…

The core lesson I’ve drawn from my rover ordeal is best expressed in these words: Let your scars serve you; they are an invaluable learning experience and investment in your capability and resilience.

There’s some good insights in this year’s 2023 State of DevOps Report. It’s well worth skimming through. Things like this aren’t exactly surprising, but it’s nice to have some data around it:

Teams with generative cultures, composed of people who felt included and like they belonged on their team, have 30% higher organizational performance than organizations without a generative culture.

Ed Zitron’s newsletter is kind of a hate-read for me because his vitriol knows no end and it can be a lot… but I think he did pretty well in his response to Marc Andreessen’s latest essay:

This is Andreessen’s dream—a continual race to the bottom where the tech industry is incentivized not to solve problems, but to find ways to make already-solved problems cheaper to solve so that venture capitalists can make money.

That’s a good quote, but please don’t stop there. The whole essay is the best rebuttal I’ve seen so far.

This is a thoughtful, well-argued essay by Benedict Evans about where we’re at with LLMs.

Whenever we get a new tool, we start by forcing it to fit our existing ways of working, and then over time we change the work to fit the new tool. We try to treat ChatGPT as though it was Google or a database instead of asking what it is useful for. How can we change the work to take advantage of this?

This is an older post from Lorin Hochstein but it’s new to me, and really insightful. It’s about how to best use our knowledge about the past behavior of a software system to figure out where we should invest our time to improve the system—and how the common method of error budgets is generally not a good way to do this:

I’m skeptical about relying on predefined metrics, such as reliability, for getting insight into the risks of the system that could lead to big incidents. Instead, I prefer to focus on signals, which are not predefined metrics but rather some kind of information that has caught your attention that suggests that there’s some aspect of your system that you should dig into a little more.

So basically, vibe-based incident analysis is where it’s at.

Since I prefer reading over watching, I appreciate Dave Rupert’s summary of this video about AI/LLM responsibility in his post Uncovering a new class of responsibilities:

Three rules of technology outline their nearly hour long talk:

1. When you invent a new technology, you uncover a new class of responsibilities
2. If that tech confers power, it starts a race
3. If you do not coordinate, the race ends in tragedy

It’s those last steps that are the concerning ones. If we fail to respond to #1, we end up with #3.

Here’s a good post from Gergely Orosz discussing Interesting Learnings from Outages. It covers internal vs. public postmortems, how investing in reliability can have bumps along the way, and how to make the difficult decision to try and fix something on the spot, or to do a lengthy restore. This point stood out to me:

“Move fast with autonomous teams” often builds up infrastructure debt. Reddit is a fast-moving scaleup where teams move fast, and it sounded like they had autonomy in infrastructure decisions. The wide range of infra configurations caused several outages, and the company is now paying down this “infrastructure debt.” This is not to say that autonomous teams moving fast is a bad thing, but it’s a reminder that this approach introduces tradeoffs that could impact reliability and will eventually have to be paid down, often by dedicated teams.