Masters3d

Technical. Creative. Tactical. Director.

Tag: systems-thinking

Posts connected by the systems-thinking tag.

14 posts

Two Left Socks

My spouse recently ended up with two left toe socks and no way to wear them, because each one had lost the only sock that matched it. My drawer, and now our kids' drawers, cannot have that problem: the kids and I wear one style of sock for every occasion, so any two make a pair. Our socks are fungible. Shoes have good reason to come in lefts and rights, but socks do not need that complication, and neither do most of the systems I build. Do not build systems that need a specific matched pair when a part that fits anywhere would do.

Read more →

Development vs Production

Building a product and running it are two different kinds of work. Development ends when the thing exists; production never ends, and what it teaches has to flow back into the product as its own stream of work. Treating the two as one job hides the second one, and the accounting split between cost of goods sold and operating expenses turns out to describe the same line.

Read more →

Quality Engineering vs Engineering Quality

Engineering quality is a property of what ships. Quality engineering is the practice that produces it, and that practice cannot be handed to another team. Quality, security, and documentation belong to the engineer who builds the thing, and the reward system has to pay for those behaviors or they quietly stop.

Read more →

The Last 20% and the Next Nine

The first 80% of a feature gets the demo, the congratulations, and the promotion packet. The last 20% (the part that makes the thing actually usable) costs a magnitude more and is rewarded far less. The reason is structural: every additional nine of reliability is a different engineering problem than the one before it, and you cannot reach it by extending a design that was never built for it. In the age of AI, when the token cost of writing the scalable version is roughly the token cost of writing the disposable one, the V1-then-rewrite habit deserves a second look.

Read more →

Far Away Is the Same as Far in the Future

You cannot drive a Mars rover with a joystick, because the round trip for a radio signal runs six to forty-four minutes. Distance and delay are one constraint measured in two different units, and once the round trip is slower than the thing you are controlling, central control stops being inefficient and becomes impossible. The physics version of the argument for autonomy at the edge.

Read more →

Signal-to-Noise, Taken Literally

People praise someone for having a 100% signal-to-noise ratio. Borrowed back from the field it came from, that is not a compliment, it is an impossible measurement. What SNR actually means, why the opposite of noise is information rather than signal, and what a headset with a microphone on it says about being a transmitter and a receiver at the same time.

Read more →

Elon's Algorithm: A Reference for the Manual Process

A reference write-up of Musk's five-step algorithm and what each step is supposed to mean when the thing being improved is a manual process in software engineering. Question the requirement, delete the step, simplify, accelerate, automate. Mostly a description of what the algorithm claims rather than an argument that it is correct, with a short closing note on where I do agree, in particular the rule that if you are not occasionally adding things back you are not cutting enough.

Read more →

Shift Left Until the PR Is Just a Confirmation

Agentic tooling made pull requests cheap and plentiful, so the bottleneck moved from writing code to trusting it. The answer is not another review loop but front-loaded rigor: invest the engineering effort ahead of time to build a full, production-shaped synthetic environment you run locally, so that validation itself becomes cheap and the PR turns into a context-sharing mechanism instead of an approval gate. Tools like .NET Aspire and Dapr show what that inner loop can look like, and the same principles carry over to homegrown systems.

Read more →

Blameless Engineering: No Heroes, Just Systems

Blameless engineering, borrowed from Google's SRE culture, is usually filed under postmortems. But the postmortem is only the last place the culture shows up. Blamelessness shifts all the way left into how you design systems, and it lands on one uncomfortable rule: the team is the unit of work, and heroes are a symptom of a system that is not yet well crafted. In the age of agents, where there is no one to blame, that rule stops being a nicety and becomes the only way to debug at all.

Read more →

A Case Against Using the Word 'Bad' in Engineering

I used to say bad version, bad rollout, bad payload. I stopped, because a version isn't good or bad in the abstract. It's a distribution of outcomes across a population of users, configs, and use cases. The same payload can be flawless for 99% and broken for 0.5%, and calling it bad collapses that spectrum onto one label that quietly dictates how you triage, communicate, and remember the incident.

Read more →

Fearless Engineering

When I was starting out, hesitation held me back from trying things. Over time it faded, not because I got braver, but because I got a better handle on risk. Fearless engineering is not the absence of caution. It is a calculated read of what you know, what you do not, and how far a change can reach.

Read more →

Orthogonal, Not Opposite

Salty is not the opposite of sweet. They are separate receptors, separate dials, and salted caramel exists because you can turn up both at once. Most 'balance' advice is secretly slider-thinking. The method is to catch the false opposite, test for a real tradeoff, and go to the corner everyone told you was impossible.

Read more →

Minimize Humans as Glue

Tanya Reilly's 'Being Glue' names the invisible human work that holds a team together but never shows up on your own record. The deeper pattern is the same one behind every high-maintenance system: a person standing in for a fix that was never made. The goal is not to be better glue, it is to build systems that heal themselves so humans are needed as glue as rarely as possible.

Read more →