In order to succeed at production ownership, a team needs a roadmap for developing the necessary skills to run production systems. We don’t just need production ownership; we also need production excellence. Production excellence is a teachable set of skills that teams can use to adapt to changing circumstances with confidence. It requires changes to people, culture, and process rather than only tooling.

…

Even a perfect set of SLOs and instrumentation for observability do not necessarily result in a sustainable system. People are required to debug and run systems. Nobody is born knowing how to debug, so every engineer must learn that at some point. As systems and techniques evolve, everyone needs to continually update with new insights.

Will Larson:

Standardizing technology is a powerful way to create leverage: improve tooling a bit and every engineer will get more productive. Adopting superior technology is, in the long run, an even more powerful force, with successes compounding over time. The tradeoffs and timing between standardizing on what works, exploring for superior technology, and supporting adoption of superior technology are at the core of engineering strategy.

An effective approach is to prioritize standardization, while explicitly pursuing a bounded number of explorations that are pre-validated to offer a minimum of an order of magnitude improvement over the current standard.

Dan Slimmon:

Ideas are funny things. It can take hours or days or months of noodling on a concept before you’re even able to start putting your thoughts into a shape that others will understand. And by then, you’ve explored the contours of the problem space enough that the end result of your noodling doesn’t seem interesting anymore: it seems obvious.

…

But as you get into more senior-type engineering roles, your most valuable contributions start to take the form not of concrete labor, but of conceptual labor. You’re able to draw on a rich mental library of abstractions, synthesizing and analyzing concepts in a way that only someone with your experience can do.

Dan Slimmon:

When building a dashboard, start with a set of questions you want to answer about a system’s behavior, and then choose where and how to add instrumentation; not the other way around.

…

The incident response team’s common ground is their theory of the system’s behavior – in order to make troubleshooting observations meaningful, that theory needs to be kept up to date with the data.

A look at the Svelte reactive Javascript framework. Compilers strike again.

Peter Coy:

The purpose of quadratic voting is to determine “whether the intense preferences of the minority outweigh the weak preferences of the majority,”

This is something I’d like to try in planning meetings.

We’ve repurposed the idea of a technology tree, popular in many strategy video games, and used that as a vehicle to communicate the Up product roadmap.

It’s effective.

Using Javascript Proxies to provide immutable data with a native feel.

Sarah Leo:

At The Economist, we take data visualisation seriously. Every week we publish around 40 charts across print, the website and our apps. With every single one, we try our best to visualise the numbers accurately and in a way that best supports the story. But sometimes we get it wrong. We can do better in future if we learn from our mistakes — and other people may be able to learn from them, too.

Herb Caudill:

Once you’ve learned enough that there’s a certain distance between the current version of your product and the best version of that product you can imagine, then the right approach is not to replace your software with a new version, but to build something new next to it — without throwing away what you have.

Gregor Hohpe:

First and foremost, autonomous teams need to live with the consequences of their decisions.

Yep.

A tired subject but a solid analogy.

David Gasca:

“Silent Meetings” are meetings where most of the time is spent working and not talking. When done correctly most of the meeting is spent silently working together.

A look at radical transparency at the hedge fund Bridgewater.

The man can tell a story.

I’ve been playing with Sketch.systems a bit already. This post looking into adding verification on top of it.

Paul Biggar:

Dark is a holistic programming language, structured editor, and infrastructure, for building backend web services. It’s aimed at frontend, backend, and mobile engineers.

Soup to nuts.

Tim Winton:

Australia is a place with more land than people, more geography than architecture. But it is not and never has been empty. Few landscapes have been so deeply known.

A post that builds up from simple princples. It looks into React, its programming model, its goals, and the trade offs it takes in solving its design challenges.

Jason Cohen:

Startup strategy is like Kung Fu. There are many styles that work. But in a bar fight, you’re going to get punched in the face regardless.

I can only teach you my style. Others can only teach you theirs.

Lots to chew on.

the research is clear: Telling people what we think of their performance doesn’t help them thrive and excel, and telling people how we think they should improve actually hinders learning.

…

The only realm in which humans are an unimpeachable source of truth is that of their own feelings and experiences.

Chris Rackliff:

Speaking of lifting others up, your core group of friends can make or break your life. And your participation can make or break theirs as well.

Matt Linderman:

Instead of working with a thing you love, think about how to work in a way you love.

This is totally my bag.

Still trying to learn how to think better.

Cindy Sridharan quoting Joe Armstrong:

We should identify the error kernel. The error kernel of a system is that part which must be correct. That’s what the error kernel is. All the other code can be incorrect, it doesn’t matter. The error kernel is the part of the system that must be correct. If it’s incorrect, then all bets are off. The error kernel must be correct.

John D. Cook:

The rule of three gives a quick and dirty way to estimate these kinds of probabilities. It says that if you’ve tested N cases and haven’t found what you’re looking for, a reasonable estimate is that the probability is less than 3/N. So in our proofreading example, if you haven’t found any typos in 20 pages, you could estimate that the probability of a page having a typo is less than 15%.