The Fastest Way to Be Done

2026-02-06T00:00:00+00:00

The fastest way to be done with dinner is to not clean the kitchen.

If you don’t clean the kitchen, a mess builds up. The pots and pans pile in the sink. The spoon you need is somewhere under something else. You may have to scrape dried spaghetti from last Tuesday or rinse peanut butter from a knife before you can use it. But eventually you will find what you need, and dinner will happen.

And still, the fastest way to be done with dinner is to not clean the kitchen.

That’s what makes this hard. You can always be done faster today if you don’t clean today. The time spent wiping the counter or putting the knife back is time not spent eating.

This is why skipping cleanup keeps winning. What’s measured is that dinner was made. The outcome. The visible result. Not how much effort it took to get there, and not how much harder it made the next dinner.

The same thing happens when decisions are made under pressure. There isn’t enough time. There isn’t enough understanding yet. You don’t have all the data, and you may not even know what the real problem is. But something has to ship, so choices are made with what’s available. Structure bends a little. Cleanup waits.

And it works. Dinner happens. Features ship.

If you cleaned the kitchen after dinner every day, the total time spent making dinner over a year would be far less. But that advantage only appears over time, and time over time is rarely what’s being measured. The mess doesn’t announce itself. It accumulates quietly and shows up later as friction.

At some point, more effort goes into working around the kitchen than into cooking. So things get rearranged. Shelves are moved. Tools are reorganized. The goal is to make tomorrow easier.

In software, this is when code gets refactored. In organizations, this is when teams and responsibilities get restructured. The kitchen is rearranged to make tomorrow feel possible.

This is what happens when we optimize for now, when we move before understanding has had time to catch up. If no one intervenes, things settle into whatever feels fastest.

Over time, you begin to notice this pattern. You see how small compromises accumulate. You feel when a name no longer fits, or when a boundary has grown heavier than it needs to be.

Over time, you realize software engineering is a craft. You rename things while they are still small. You adjust structure before it stiffens. You clean a little while the system is still warm.

A good chef doesn’t wait until the end of the night to discover the kitchen is unusable. They wipe the board between steps and reset the counter before reaching for the next ingredient. It doesn’t look dramatic. It simply keeps cooking straightforward.

And still, the fastest way to be done with dinner is to not clean the kitchen.

Eventually the way you move through the kitchen becomes the kind of cook you are — and the kind your future self has to work with.

Systems As Mirrors

2025-06-21T00:00:00+00:00

There’s something quietly unsettling about Conway’s Law</a>. Most people who’ve worked in software long enough can sense its truth. What unsettles is what it reveals when you sit with it.

The law definition, in its original form, is:

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent? </blockquote>
At first, it seems structural. Org charts become system diagrams. Split your teams by department, and the system splits the same way. But over time, the reflection deepens. The system doesn’t only mirror who talks to whom — it starts echoing what’s understood, and what’s avoided.
The most confusing systems I’ve seen don’t reflect complexity. They reflect ambiguity.
You see it in familiar places. One service checks a user’s admin flag. Another checks something else entirely. A third overrides both. A field like “approved” means one thing to scoring, another to compliance, and something looser to product. The code bends around uncertainty. But what it adapts to isn’t complexity — it’s a missing decision.
This gets worse when teams try to support everything. A lending flow starts with a clean path. Then you add freelancers, students, returning users. You don’t create new flows. You add flags: hasPayslip</code>, isStudent</code>, incomeSource</code>. Logic branches. Models fork. Scenarios pile up.
Each rule makes sense in isolation. But together, they blur the center. “ApplicationApproved” starts meaning different things depending on the path taken. Eventually, no one can say what it means — only how it behaves under certain conditions.
The system still works. But its meaning doesn’t.
This is where outcome-driven modeling helps. Jobs To Be Done</a> is one approach. It shifts the focus from who the user is to what they’re trying to accomplish. It asks what outcome they’re hiring the system to deliver — and what tradeoffs they’re willing to make.
A persona tells you the user is a freelancer who prefers mobile and has irregular income. The job tells you: access a short-term loan using recent invoices. Suddenly, the model sharpens. Income is about pattern, not payslips. Risk is about volatility. Rejection isn’t the fallback — manual review is.
When you model from outcome, the system knows what it’s trying to do.
This is also where domain boundaries matter. Domain-Driven Design</a> introduces the idea of bounded contexts</a>: each part of the system defines its own meaning. Duplication isn’t always a mistake — it’s often how clarity is preserved. Reuse works best when meaning aligns.
Take the classic User</code> model. In KYC, it means identity: documents, name, status. In Scoring, it means applicant: income, employment, credit history. In Auth, it means account: credentials, sessions, MFA. Reusing the ID is fine. Reusing the model leads to something brittle: dozens of nullable fields, conflicting assumptions, tangled dependencies.
Some say duplication is always bad. But that’s a narrow view. It depends on what’s being repeated. Echoing confusion spreads it. But repeating meaning reinforces clarity. Duplication isn’t the enemy — imprecision is.
Once each model speaks a single truth, everything downstream improves. The backend is easier to debug. The frontend becomes more predictable. Changes get safer. Teams stop negotiating the meaning of basic terms and start delivering again.
And that brings us back to the mirror.
Conway’s Law tells us systems mirror their makers. But reflections go further than structure. They echo our indecision, our shortcuts, the choices we didn’t make.
So the real question is: If every system is a mirror — what part of ourselves are we willing to see?

~/iam - decision-making

The Fastest Way to Be Done

Systems As Mirrors