This is worse than either finishing or never starting, and it is the default outcome unless something prevents it.

why it costs more than both#

Two systems to maintain. Every change lands twice, or lands in one and silently diverges in the other.

Two sets of bugs, plus a third set caused by the interaction.

Nobody knows which is authoritative. New engineers ask; the answer is "it depends."

The benefit never arrives. The reason for the migration — delete the old thing, get the performance, simplify the model — is only realised at 100%. At 70% you have paid the full cost and collected none of the return.

It gets harder over time. The remaining 30% is the hard 30%: the weird integrations, the customer with the bespoke arrangement, the code nobody understands. And it gets harder as the people who understood the original migration leave.

why it happens#

Not laziness. The incentives genuinely point this way:

The easy 70% delivers most of the visible benefit. The graph goes up, the demo works, the announcement is made. The remaining 30% has no visible reward.

The hard cases are hard for a reason. They were skipped because someone did not know how to handle them, and that has not changed.

Priorities move. The migration was urgent in Q1. In Q3 there is a launch.

Nobody owns the finish. The person who drove it moved on, and completion was never anyone's explicit goal.

the mechanisms that actually work#

Name the deletion, not the migration. The project is not "migrate to the new pricing service." It is "delete the old pricing service." The deliverable is the deletion, and the migration is how you get there. This one rewording changes what people track and what counts as done.

Set a date, publicly, at the start. Not "by end of year" — a date, in the plan, with the deletion as the milestone. Dates without deletions slip silently; a date attached to "and then this code is gone" is checkable.

Make the old path visibly worse. Log a warning on every use. Add latency — genuinely, deliberately. Put a banner in the internal tool. The old path being comfortable is why nobody leaves it.

Count the stragglers on a dashboard. "Requests still on the legacy path" as a number that goes down, reviewed weekly. Anything not measured stalls at whatever level nobody notices.

Do the hard cases first. Backwards from the usual instinct and correct. The easy 70% will always be doable; the hard 30% is what determines whether the project is possible at all. Finding out in month one that a case cannot be migrated is a much better outcome than finding out in month nine.

Budget the finish before starting. If you cannot fund the last 30%, do not start. A migration you cannot complete is worse than the system you have.

the decision worth making explicitly#

Sometimes finishing genuinely is not worth it. The remaining cases are rare, the old path works, and the effort is better spent elsewhere.

That is a legitimate call — but it has to be made, written down, and the state made permanent rather than provisional:

The legacy importer stays for CSV uploads from the four enterprise customers using it. New integrations use the API. We are not migrating them; the importer is now a supported, frozen component with an owner, not a migration in progress. Reviewed 2026-09-21, revisit 2028.

That is a completely different thing from a stalled migration, even though the code looks identical. One is a decision with an owner. The other is a mess nobody has admitted to.

The cost of the second one is not the code. It is that every engineer who touches that area has to reconstruct which way things are supposed to be going, and nobody can tell them.

These correlate less than we would like, and the gap is where a lot of otherwise good software fails.

what users actually experience#

Not your service boundaries. Not your consistency model. Not the fact that you handle a partition correctly.

• How many steps to do the common thing.
• Whether it responds instantly or after a spinner.
• Whether an error tells them what to do.
• Whether it does the same thing twice in a row.
• Whether it remembers what they told it last time.

Every one of those is an interface property, and every one is achievable on top of an ugly implementation — or destroyed on top of a beautiful one.

the trade that is usually made backwards#

There is a real tension between internal cleanliness and external simplicity, and it comes up constantly:

• The clean data model exposes three concepts where users think in one.
• The correct API makes the caller specify things they do not care about.
• The properly-separated services mean the UI has to make four calls and handle each failing independently.
• The general solution has eleven configuration options; the specific one would have had zero.

The default resolution is to protect the internals and push the complexity outward, because the internals are what engineers look at and defend in review.

That is backwards. The interface is used far more times than the implementation is read. Complexity at the boundary is multiplied by every user and every call; complexity inside is paid by the people who chose it.

what this looks like in practice#

Collapse concepts at the boundary. If users think of one thing and your model has three, expose one and do the mapping internally. Yes, that is a lossy abstraction and you will occasionally have to break it. That is the correct place to put the pain.

Default everything. Every required parameter is a decision you have forced on someone who has less context than you. Make it optional with a sensible default, and let the people who genuinely need control find the option.

Make the common path one step. Count the actions for the thing 90% of users do 90% of the time. If it is more than two, that is the work.

Absorb the failure. If your architecture means four things can fail independently, the interface should not surface four independent failures. Retry, degrade, or present one coherent state.

Make it fast where they are waiting. A local read, an optimistic update, a cached response. Users cannot tell the difference between "fast because it is well-engineered" and "fast because you cheated" — and neither can anyone else.

the counterweight, honestly#

This is not an argument for shipping a nice facade over a broken system. The internals are what make the interface keep working — under load, at the edges, after a year of changes. Software that is lovely to use and impossible to change dies just as reliably, only slower.

The claim is narrower: when the two genuinely conflict, and they do, the interface should usually win — because it is what the software is for, and because interface decisions are much more expensive to reverse than internal ones. You can rewrite the storage layer. You cannot easily take back a concept you taught a million users.

the test#

Watch someone use your software for the first time without helping them.

Count the moments they hesitate. Each one is a place where your model and theirs diverged, and no amount of internal quality closes that gap.

That exercise is uncomfortable, takes twenty minutes, and consistently produces a better backlog than any amount of architectural discussion.

It has held up for a decade. It is worth restating because a decade is long enough that people have started applying it wrongly, in a specific and predictable way.

why it works#

Known failure modes. The value of a boring technology is not that it is good. It is that when it breaks at 3 a.m., the error message has been pasted into a public forum by someone who then explained the fix.

A hiring pool that already knows it. Every unusual choice is a thing you must teach every new engineer, forever.

Operational surface you can reason about. Boring things have runbooks, monitoring integrations, backup tooling, and a decade of accumulated operational wisdom.

Someone else finds the bugs. A widely-deployed system has been run at scales you will never reach, by people who reported what broke.

the amendment#

Here is what the original argument does not say, and what a decade has taught: boring is a property of a technology at a moment in time, and it moves in both directions.

Things become boring. Things also stop being boring — a project loses its maintainers, its community fragments, its corporate sponsor reorganises, the ecosystem moves and it does not.

So "choose boring" is not a decision you make once. It is a property you have to re-check, and the failure mode nobody plans for is the technology that was the safe choice in 2019 and is now a liability that everyone forgot to reconsider.

The practical version: once a year, for each load-bearing dependency, ask — is this still boring? Is it still maintained, still hired for, still the thing a new engineer would expect? A "yes" costs a minute. A "no" is the most valuable thing you will learn that quarter.

how to tell whether something is boring now#

Not by age. Some old things are unmaintained; some five-year-old things are completely settled.

The signals that actually matter:

• Multiple independent maintainers, ideally from more than one employer.
• A release in the last six months, and a changelog that shows maintenance rather than churn.
• You can hire for it. Search jobs, not GitHub stars.
• Operational documentation written by users, not just by the vendor.
• A migration path off it, documented by people who took it. A technology nobody has successfully left is a technology you cannot leave.
• Boring failure modes. Can you name what happens when it runs out of memory, loses its network, or gets a corrupt config? If nobody has written that down, it is not boring yet.

where to spend the tokens#

The argument's real content is that innovation tokens are scarce, and the scarcity is not about technology risk. It is about attention.

Every unusual choice consumes attention: to learn it, to operate it, to debug it, to explain it. Attention is the actual constraint on an engineering team, and it is far more limited than the budget.

So spend the tokens where the unusual choice is the product. If your differentiator is a query engine, be adventurous about storage and utterly boring about everything else. If your differentiator is a workflow, use the most conventional stack in existence and put all the attention into the workflow.

The teams that get this wrong are almost never wrong about one big choice. They are wrong about six small ones, each individually defensible, that together consumed all the attention that should have gone into the thing customers pay for.

the counterweight#

Taken too far this becomes an argument for never learning anything, and that is its own failure. A team that made every choice in 2016 and never revisited one is not disciplined, it is stuck — and the technology it chose has probably stopped being boring in the meantime.

The synthesis: be adventurous in one place at a time, deliberately, with a written reason. Be boring everywhere else. Re-check annually.

That is a harder discipline than either "always use the new thing" or "never use the new thing," and it is the only one that survives a decade.

It is also a permanent commitment that somebody will still be paying for in eight years. Here is the conversation worth having first.

what a service costs, in full#

Not the code. The code is the cheap part.

• A repository, a build, a deploy pipeline, a rollback path.
• A place to run, sized, with capacity headroom.
• Monitoring, alerting, dashboards, an on-call runbook.
• Secrets, credentials, and their rotation.
• Dependency upgrades and security patching, forever.
• A place in the request path that can now time out, and the circuit breaker and retry policy that implies.
• Documentation, and an owner who is still at the company.
• One more thing a new engineer must learn about.

That list is the same whether the service is four hundred lines or forty thousand. The overhead is fixed, which is why small services are the ones whose economics are worst.

the questions, in order#

1. Could this be a module?

The default answer for new functionality is a well-bounded module in something that already exists. It gets all of the above for free.

The follow-up that matters: if this were a module with an enforced boundary, what would we lose? If the honest answer is "nothing, it would just feel less tidy," write the module.

2. What is the deployment argument?

The strongest reason to extract is that a team needs to release on its own cadence and currently cannot. That is real and it scales with organisation size.

But check it: are they actually blocked, or do they merely deploy together? Two teams that could deploy independently and choose not to have a process problem, not an architecture problem, and a new service will not fix it.

3. What is the scaling argument, with numbers?

"It might need to scale differently" is not an argument. "This component is CPU-bound and spiky while the rest is I/O-bound and steady, and we are currently provisioning for the peak of both" is.

If you cannot state the resource profile that differs, there is no scaling argument.

4. Where does the data live?

The question that sinks most extractions. If the new service needs the same tables the old one does, you have not split anything — you have created two writers to one database, which is worse than one writer, and you now have to coordinate migrations across two deploy cycles.

A service that does not own its data is a distributed monolith with extra latency.

5. What happens when it is down?

If the answer is "the main flow breaks," you have added a failure mode and bought nothing in return. Fault isolation is not free; it is the result of deliberate timeouts, fallbacks and degradation, and if you are going to build those anyway you could have built them around a module.

6. Who owns it in two years?

Name the team. Not the person — the team. Services outlive their authors, and an ownerless service is the one that runs three major versions behind until it is a security incident.

the cases where the answer is yes#

Being fair, because the reflex against splitting can be as unexamined as the reflex toward it.

• A genuinely different resource profile, with numbers.
• A compliance or data-residency boundary that must be enforced structurally.
• A component that has to be written in a different language for a real reason.
• A team that is demonstrably blocked on someone else's release cadence.
• Something with wildly different availability requirements — a batch job that can be down for an hour next to a checkout path that cannot.

In every one of those, the service is buying something specific that a module cannot.

the reversibility test#

Before you create it, ask: if this turns out to be wrong, how do we merge it back?

If the answer is "we would not, we would just live with it," you are making a one-way decision on a hunch. Those deserve more scrutiny than they usually get, and the moment before the repository exists is the last time the scrutiny is free.

what it did to my engineering#

It forced me to actually understand things. You can hold a fuzzy model of a technology in your head indefinitely and it feels like knowledge. The moment you try to explain it in a paragraph, the fuzziness becomes visible.

I have abandoned drafts because I discovered, four hundred words in, that I did not understand the thing well enough to write about it. Every one of those was more educational than the pieces I finished.

It made me check things. Writing "X is faster than Y" in public means someone will ask for numbers. Knowing that in advance changes how you form the belief in the first place.

It made me notice my own patterns. Reading two hundred pieces of my own writing back, the recurring themes are obvious to me now and were invisible while writing: verification over generation, boring over clever, measurement over intuition, and a persistent suspicion of anything that requires you to trust rather than check.

I did not set out with a thesis. It assembled itself.

It taught me to be wrong in public, which is a skill and is uncomfortable and is the only way to find out you were wrong quickly.

what I have been most wrong about#

I graded myself in December and the pattern held for the following eight months.

I am reliably right about technical trajectories and reliably wrong about adoption.

Local models got good; people did not switch, because hosted models got cheap faster than I expected. RAG got less necessary; the infrastructure repositioned instead of dying, which I have now failed to predict three separate times. Registry security controls were obviously needed; they arrived after the incident rather than before.

The lesson I keep relearning: the technology is the easy part to forecast, and the technology was never the hard part. Human and organizational behavior is where the uncertainty lives and where the consequences land.

I under-predict inertia and over-predict rationality. Almost every wrong call has that shape.

the thing about writing news#

Two hundred pieces, roughly half of them about things that happened in a specific week.

Reading them back, the ones that held up are almost never the ones that reported the event. They are the ones that used the event to explain a mechanism.

Nobody needs my summary of what a company announced. They can read the announcement. What is worth writing is: why does this shape of thing keep happening, and what does it imply for what you should do on Monday.

The news is a prompt. The mechanism is the article.

I did not know that when I started and it took about forty pieces to figure out.

on the archive#

Everything published here is still at its original URL. Nothing has been quietly edited, renamed, or removed. Corrections are marked in place.

That is a deliberate choice and it costs something — there are pieces I would write differently now, and a few I think are wrong.

Leaving them up is the point. A publication that silently revises its history is not a record, it is a marketing surface. The value of an archive is that it shows what someone thought at the time, including when that was wrong, and you can only get that by not touching it.

If you want to know whether to trust a technical writer, check whether their old pieces still exist and whether the wrong ones were corrected in the open.

on the format#

Gray background. Monospace headings. One column. No popups, no cookie banner, no newsletter modal, no autoplaying anything, no third-party JavaScript on any page.

This is not minimalism as an aesthetic. It is that every one of those things was added to a website to serve the publisher at the reader's expense, and the cumulative effect has made reading on the web genuinely unpleasant.

A page should render before you notice it loading. Text is the interface. Nothing moves unless the reader moved it.

Those are not hard constraints to meet. Almost nobody meets them, and the reason is never technical.

the next two hundred#

Same beat. Tech, developers, and the code underneath. News where the news teaches something, essays where the news does not.

More on the verification problem, because it is the defining engineering question of this period and it is nowhere near resolved. More on the craft, because the craft is what survives the tooling cycles. Fewer pieces about model launches, because they have stopped being informative.

Thanks for reading. Corrections are always welcome and get priority over everything else.

— Dom

Deleting code is the only refactoring that is unambiguously good. It cannot introduce a bug in the deleted code, because there is no deleted code. It reduces build time, test time, cognitive load, security surface, and the probability that someone reads the wrong thing.

And nobody schedules it.

what accumulates#

Dead code. Never called. Nobody noticed, because nothing fails when unused code exists.

Features nobody uses. Built for a customer who churned, an experiment that ended, a requirement that changed. Still there, still tested, still maintained, still appearing in every search result.

Abandoned abstractions. Someone built a plugin system for the second plugin, which was never written. Now every call goes through a registry that has one entry.

Configuration for conditions that no longer occur. A flag for a migration that completed in 2023.

Compatibility shims. For a version nobody runs, an API that was removed, a browser that no longer exists.

Tests for deleted behavior. Still running, still slow, testing something that cannot happen.

Vendored copies. Of a library that is now a real dependency.

Commented-out code. Always. Delete it. Git remembers.

how to find it#

Coverage, over a long window. Run coverage in production if your language supports it, or over your full integration suite. Anything at zero across a month is a candidate.

Be careful: zero coverage does not prove dead. It might be an error path, a rare branch, or something exercised only in a region you did not sample. Verify before deleting.

Static analysis for unreachable code. Most linters find unreferenced functions within a module. Cross-module dead code is harder and several tools do it.

Feature flags at 100% for over a quarter. The disabled branch is dead code with a switch on it.

Endpoints with no traffic. Log every route. Anything with zero requests in ninety days is a candidate. This is trivially easy to check and almost nobody does.

Deprecation warnings nobody triggers. If you have been logging a deprecation warning for a year and it has never fired, the deprecated thing is unused.

git log on the file. Anything untouched for three years in an actively developed codebase is either perfect or forgotten.

how to do it safely#

Log before you delete. For anything you are not certain about, add logging and wait. A month of zero calls is strong evidence.

def old_thing(x):
    log.warning("old_thing called", stack=traceback.format_stack())
    return new_thing(x)

Delete in a separate commit from any other change. A deletion mixed with a refactor is unreviewable and un-revertable.

Delete the tests too. Tests for deleted code are the most common thing left behind and they will confuse the next person enormously.

Do not comment it out. Do not move it to an old/ directory. Do not keep it "just in case." Git has it. If you genuinely might need it, note the commit hash in the deletion's commit message.

Do it in batches, by area. One area, fully cleaned, is better than a thousand scattered deletions that are impossible to review.

the resistance you will meet#

"What if we need it?" You will not. And if you do, it is in git. In many years I have never seen a team need to recover deleted code that they could not recover.

"Someone might be using it." Measure. That is what the logging is for. Guessing in either direction is worse than checking.

"It works, why touch it?" Because it costs. Every line is read by every person who greps this file, is compiled on every build, is scanned by every security tool, and is a possible place for a future bug.

"That is not a priority." Correct, and it never will be, which is why it has to be scheduled rather than prioritized. Ten percent of one sprint, quarterly, with a line count as the deliverable.

the framing that gets it done#

Make it a competition. Track lines removed. Celebrate the largest deletion of the quarter.

This is slightly silly and it works, because it inverts the default incentive. Engineers are implicitly rewarded for adding — features shipped, code written — and never for removing, even though removing is frequently worth more.

Naming it, tracking it, and praising it is enough to change the behavior.

the number#

A large fraction of most mature codebases is dead or effectively dead. I have never audited one where it was under 10%, and I have seen 40%.

Every line of that is being read, compiled, tested, scanned, and maintained, at a cost nobody has ever measured.

Go find some.

Here is a way to actually decide.

the cost of lock-in#

Switching cost. How much engineering time to move off, if you had to.

Pricing power. A vendor who knows you cannot leave prices accordingly. This is real and it is usually the largest ongoing cost.

Capability ceiling. You are limited to what they support, on their timeline.

Correlated risk. They have an outage, you have an outage. They change their terms, you comply. They get acquired and sunset the product, you migrate on their schedule.

the cost of avoiding lock-in#

This is the half that gets ignored, and it is frequently larger.

The abstraction layer itself. Code to write, maintain, test, and debug through. It is a permanent tax and it makes stack traces longer.

Lowest common denominator. Your abstraction can only expose what all candidate providers support. You give up the features that made the good option good.

The abstraction is usually wrong anyway. It was designed against one provider's model. When you actually try to swap, you discover the abstraction encoded assumptions that do not hold, and you rewrite it.

Delayed value. Time spent on portability is time not spent on the product.

the framework#

For each dependency, estimate:

1. Switching cost — engineer-weeks to move.
2. Probability you switch in the next three years.
3. Cost of the abstraction — engineer-weeks now, plus ongoing drag.

Then: if switching_cost × probability < abstraction_cost, do not abstract.

The numbers are rough. The exercise still clarifies, because it forces you to state the probability out loud, and stated probabilities are usually much lower than the implied ones people are acting on.

the categories, worked through#

Object storage. Switching cost: low. The S3 API is a de facto standard and every provider implements it. Probability: moderate — people do move for pricing.

Verdict: use the S3 API, do not abstract further. The API is already the abstraction.

Compute. Switching cost: moderate if containerized, high if you use provider-specific serverless. Probability: low.

Verdict: containerize — which is good practice anyway — and use whatever managed service you want. Do not build a compute abstraction layer.

Relational database. Switching cost: high. Probability: low.

Verdict: use the database's features. Teams that avoid stored procedures, database-specific types, and advanced indexing to stay portable are giving up real capability for an event that will not happen. Postgres-specific SQL is fine. You are not going to migrate to a different engine, and if you do, the SQL dialect will be the smallest part of the pain.

Managed queues, streams, and similar. Switching cost: moderate. The semantics differ enough between providers that a thin abstraction genuinely helps.

Verdict: a thin interface — publish, subscribe, ack — is worth it. Not a full abstraction; a boundary.

Authentication. Switching cost: very high — you have to migrate user credentials, sessions, and integrations. Probability: low, but the consequences of being stuck are severe.

Verdict: use standard protocols. OIDC and SAML are the abstraction. A provider that supports them is replaceable in principle; one with a proprietary SDK is not.

AI model providers. Switching cost: low if you kept the interface thin. Probability: high — the market is moving fast and the right choice changes quarterly.

Verdict: definitely abstract. This is the clearest case on the list. A thin interface plus an eval harness in your own repository makes model changes an afternoon. Teams that did this in 2024 have been switching providers casually ever since.

Observability. Switching cost: moderate to high — instrumentation is everywhere in your code. Probability: moderate, usually driven by cost.

Verdict: OpenTelemetry. The instrumentation is vendor-neutral, the collector handles routing, and swapping backends is a configuration change.

the pattern#

Abstract where the switching probability is high and the abstraction is cheap. AI providers, observability backends, object storage.

Do not abstract where switching is unlikely and the abstraction costs you real capability. Databases, compute platforms, managed services you chose for their specific features.

Use standard protocols wherever they exist. OIDC, S3, OpenTelemetry, SQL. A standard is an abstraction someone else maintains, and it is always cheaper than yours.

the thing that actually protects you#

Not an abstraction layer. Your data, in a format you can export, and a documented process for leaving.

Ask, before adopting anything: can I get all my data out, in a usable format, without their cooperation? If yes, you have real optionality regardless of how coupled your code is, because the expensive part of a migration is never the code — it is the data.

If the answer is no, that is a much bigger red flag than any API coupling, and it is the question almost nobody asks during procurement.

the actual trade#

Native gives you: full platform capability, best performance, platform-idiomatic interface, immediate access to new OS features, and the best debugging tools.

It costs you: two or three codebases, two or three teams, features implemented multiple times, and behavior that diverges over years in ways nobody tracks.

Cross-platform gives you: one codebase, one team, features implemented once, consistent behavior.

It costs you: a framework layer between you and the platform, a lag before new OS features are available, worse debugging when the problem is in the bridge, and an interface that is either non-idiomatic on every platform or requires platform-specific work anyway.

the thing the arguments miss#

The largest cost of cross-platform is not performance. It is the escape hatch.

Everything is fine until you need something the framework does not support. Then you are writing platform-specific native code, plus a bridge, plus a fallback, plus tests for all three — and you have the complexity of native development plus the framework.

This happens. It always happens. The question is how often, and that depends entirely on what your app does.

Low escape-hatch pressure: content, commerce, forms, dashboards, CRUD, most business applications. These use the standard widget set and standard capabilities. Cross-platform works well.

High escape-hatch pressure: camera and media processing, background execution, Bluetooth and hardware peripherals, complex custom rendering, deep platform integration (widgets, shortcuts, app extensions), anything real-time.

For high-pressure apps, cross-platform frequently costs more than native, because you pay for the framework and then write the native code anyway.

Be honest about which one you are before choosing. Most teams that regret their choice were high-pressure and assessed themselves as low.

the options, honestly#

React Native. Mature, large ecosystem, native widgets. The new architecture removed the old asynchronous bridge, which was the main performance complaint. Best choice if your team is already React.

Flutter. Renders its own widgets, which means true visual consistency and a non-native feel that some users notice and most do not. Excellent performance for custom interfaces. Dart is a real adoption cost for a team that does not know it.

Kotlin Multiplatform. Share business logic, write native UI. This is the approach I find most defensible: the logic layer — networking, models, validation, persistence — is where duplication is most wasteful and least visible to users, and the UI layer is where platform idiom matters most.

Requires two UI implementations, which is the point rather than a limitation.

Web technologies in a wrapper. Fastest to build if you have web engineers, and the platform feel is the weakest. Fine for content-heavy applications, poor for anything interaction-heavy.

Native. Still correct for a large category, and the category is smaller than native advocates believe.

the organizational question that actually decides it#

Do you have or can you hire two platform teams?

If yes, native is viable and gives you the best result.

If no — and for most companies below a certain size the answer is no — the choice is between cross-platform and shipping on one platform. Framed that way, the decision is usually easy.

What is your feature velocity?

If you ship a large feature monthly, implementing it twice is a permanent 2× cost on your most expensive activity. If you ship quarterly, the duplication matters less.

How much does platform idiom matter to your users?

For a consumer app competing on polish: a lot. For an internal tool: nothing. For a B2B product where the buyer is not the user: less than you think.

the hybrid that most people should consider#

Share the logic, write the UI natively.

The business logic — API clients, data models, validation, offline storage, sync, analytics — is genuinely identical across platforms and duplicating it produces bugs that exist on one platform and not the other, which are the worst bugs to diagnose.

The UI is where platform conventions matter, where users notice, and where the framework abstraction costs the most.

This is more work than full cross-platform and less than full native, and it puts the sharing where the value is.

the thing I would tell someone deciding#

Prototype the hardest thing first.

Not the login screen. The thing you are worried about — the camera flow, the background sync, the complex list, the offline behavior. Build that on your candidate stack, in a week.

You will learn more from that week than from any amount of comparison, and you will learn it while changing your mind is still cheap.

The teams that regret their choice almost always chose based on a comparison article, built the easy part first, and discovered the hard part in month five.

Here is an attempt at what the role actually is, based on watching people do it well.

what it is not#

Not "a senior engineer who has been there longer." Time in seat produces a senior engineer with more context, which is valuable and is not this.

Not "the best coder." The highest-output individual contributor is a valuable role and it is a different one. Staff engineers frequently write less code than seniors.

Not "a manager who did not want to manage." The scope is comparable to a manager's; the mechanism is entirely different.

what it is#

The concise version: a staff engineer is responsible for the technical success of work that spans more than one team, without having authority over those teams.

Everything distinctive about the role follows from "without authority." You cannot assign work. You cannot approve headcount. You cannot make a decision stick by deciding it. Every outcome has to be achieved through information, credibility, and persuasion.

the actual activities#

Finding the problem nobody owns. The most common form of staff-level impact. Every organization has problems that fall between teams: the shared library nobody maintains, the integration that fails and each side thinks is the other's, the performance issue that is caused by the interaction of three services.

Nobody owns these, so nobody fixes them, so they persist for years. Identifying one, proving it matters, and getting it fixed is a substantial contribution and it usually requires a person who is not on any of the teams involved.

Making a decision that spans teams. Which of three approaches, when each team has a preference and none of them can see the whole picture. This is where the "no authority" constraint bites hardest: the decision has to be made in a way that the people affected accept, which means the reasoning has to be visible and the objections have to be genuinely addressed.

Writing the document that ends the argument. A recurring disagreement that resurfaces every quarter because nobody wrote down the resolution. One good document — with the options, the trade-offs, the decision, and the reasoning — can end a multi-year debate.

Being the person who read the whole system. Most engineers know their team's code. Somebody needs to know how it all fits together, including the parts nobody has touched in three years. That knowledge is what makes the cross-cutting problems visible.

Raising the floor. Not by writing better code. By making the good pattern easy: a library that removes a class of bug, a template that encodes the right defaults, a lint rule that prevents the mistake, documentation that means nobody has to ask. Impact through leverage rather than output.

Mentoring, specifically on judgment. Not "how do I use this API." "Should we build this at all," "how do I disagree with my manager about a technical decision," "how do I tell if this design will be a problem in a year."

Saying no with a reason, at a level where it lands. Frequently the most valuable thing a staff engineer does, and the reason it requires seniority is that the no has to come with an alternative and with credibility behind it.

the day, concretely#

A real week looks roughly like:

• 20% writing code, usually the hard or risky part of something, or a prototype that settles an argument.
• 25% writing documents — designs, decisions, analyses, postmortems.
• 25% in conversations — reviews, one-on-ones, arguing about designs, being asked "does this seem right to you."
• 15% reading — code, incident reports, other people's designs, the thing everyone is complaining about.
• 15% on whatever is currently on fire.

The proportion of coding is the part that surprises people moving into the role, and the discomfort of not shipping visible code is the most common reason people bounce out of it.

how to tell if someone is good at it#

Do things get decided? Not "do they have opinions." Do arguments they are involved in reach a resolution that holds.

Do other engineers get better? Look at the people around them over a year.

Do they work on things nobody asked them to? The highest-value staff work is usually self-directed, because if it were obvious and assigned it would already have an owner.

Are they trusted by people who disagree with them? This is the real test. Someone who is only trusted by people who already agree has influence, not credibility.

the failure modes#

Becoming an architecture astronaut. Designs, diagrams, opinions, no contact with running code. The credibility runs out within about a year, and it is very hard to get back.

Becoming a very expensive senior engineer. Doing excellent work with single-team scope. Comfortable, valuable, and not the job.

Spreading too thin. Involved in twelve things, effective in none. The scope is tempting and the constraint is real: two or three significant efforts at a time is the realistic maximum.

Losing the ability to build. The role requires enough hands-on work to stay credible and calibrated. An engineer who has not shipped in a year is guessing.

It has exceptions, and knowing which situation you are in matters more than knowing the rule.

why rewrites usually fail#

The old system's behavior is undocumented and load-bearing. Every strange conditional in a decade-old codebase is a bug report somebody filed. You will not find them by reading the code, because the code does not say why. You will find them by shipping the rewrite and having those bugs re-reported.

The rewrite has no users, so it gets no feedback. The old system is being exercised by real traffic continuously. The new one is exercised by your test suite, which encodes what you think it should do.

Feature parity is a moving target. The old system keeps getting features, because the business does not stop. You are chasing a target that recedes, and the chase consumes the time you budgeted for the rewrite.

Nobody can justify continuing past month six. The rewrite has produced nothing users can see. The pressure to redirect the team to visible work is enormous and usually wins, leaving you with two systems.

The knowledge is in the people, not the code. And the people who knew have frequently left, which is often why the rewrite was proposed.

the three cases where it is right#

1. The platform is dead.

The framework is unmaintained, the language runtime is past end-of-life and getting CVEs, the vendor discontinued the product, the hardware is unobtainable.

This is not a preference — you are being forced. Rewrite, and be grateful you found out before the security incident.

2. The domain model is fundamentally wrong.

Not "the code is messy." The core abstractions do not correspond to reality, and every feature requires working around them.

The test: can you name a specific business capability that is impossible, not just awkward, in the current model? "We cannot support customers with more than one billing entity, and the fix requires changing what a customer is."

If you cannot name one, you have messy code, not a wrong model, and messy code is fixed by refactoring.

3. The system is small enough that the rewrite is short.

If the whole thing is three weeks of work, the calculus changes entirely. The risk of a three-week rewrite is bounded. Just do it.

The received wisdom is about large systems, and people apply it to small ones where it does not hold.

how to do it when you must#

Strangler fig, never big bang.

Put a routing layer in front of the old system. Move one endpoint at a time to the new implementation. Route traffic gradually. When everything has moved, delete the old system.

             ┌─→ new service (endpoints A, B)
client → router
             └─→ legacy monolith (everything else)

Properties this gives you:

• Value ships continuously. Every migrated endpoint is a delivered improvement.
• Risk is bounded per endpoint. If one goes wrong, route it back.
• The project survives leadership changes, because it is producing visible progress the whole time.
• You learn the old system's real behavior incrementally, at the point where you have to reimplement it.

Run both and compare. For a while, send traffic to both implementations, return the old one's response, and log the differences. This is the single most effective technique for discovering undocumented behavior, and it finds things no amount of code reading would have.

old = legacy.compute(req)
try:
    new = rewritten.compute(req)
    if new != old:
        log.warn("divergence", request=req, old=old, new=new)
except Exception as e:
    log.error("new path failed", error=e, request=req)
return old      # old is still authoritative

Run that for weeks. The divergence log is your actual specification.

Freeze the old system's features. If the business keeps adding to it, you will never catch up. This requires an explicit organizational decision and it is usually the hardest part.

Set a deletion date and mean it. The worst outcome is two systems forever. If the migration stalls at 70%, you have doubled your maintenance surface permanently.

the question to ask first#

Before any rewrite: what specifically will be better, and how will you know?

If the answer is "the code will be cleaner," that is not a business outcome and the project will lose its funding to something that is.

If the answer is "features in this area will take one week instead of three, and here are the last five that took three," you have a case.

The rewrites that succeed are the ones where somebody could state the payback in a sentence. The ones that fail are the ones motivated by taste, and taste is not wrong — it is just not fundable.

The physics is real. The applicability is narrower than the marketing, and the reason is data.

the physics#

Light in fiber travels roughly 200,000 km/s. New York to London and back is about 55 ms of pure propagation, before any processing. Add TLS handshakes, TCP setup, and real-world routing that is not a great circle, and a cross-Atlantic round trip is frequently 100 ms or more.

Running code 20 ms from the user instead of 120 ms is a genuine improvement and it is not achievable any other way.

the problem#

Your data is not at the edge. It is in a database, in one region, and if your edge function needs it, you have moved the compute closer to the user and left the round trip in place — plus added a hop.

user → edge (5ms) → origin database (120ms) → edge → user

That is slower than the user talking to the origin directly, because you added a hop to a path that was always dominated by the database call.

This is the single most common edge computing mistake and it is easy to make, because the architecture diagram looks right.

what edge is genuinely good for#

Anything that needs no origin data:

• Redirects and rewrites. URL normalization, locale routing, legacy path mapping.
• Authentication token validation. A signed JWT can be verified with a public key at the edge, and an invalid request never reaches your origin. This is a real win — you reject bad traffic at the perimeter.
• A/B test assignment. Deterministic hash of a cookie into a bucket. No state required.
• Header manipulation. Security headers, CORS, feature policy.
• Bot filtering and rate limiting. Reject at the edge, before the request costs you anything.
• Personalization of cached content. Fetch the cached page, inject the user's name from a cookie, return. The expensive part stays cached.

Anything where the data is genuinely replicated to the edge:

Several platforms now offer edge-replicated key-value and SQL storage. If your data is small, read-heavy, and tolerant of replication lag — configuration, feature flags, product catalogs, translations — this works well and the latency win is real.

The constraints are real too: writes go to a primary, replication is eventual, and storage per location is limited.

what edge is bad for#

Anything write-heavy. Writes need coordination. Coordination needs a primary. The primary is in one place.

Anything requiring strong consistency. By definition, this needs coordination, which needs round trips, which is what you were trying to avoid.

Anything with a large working set. You cannot replicate a terabyte to three hundred locations.

Anything computationally heavy. Edge runtimes have tight CPU and memory limits. They are designed for milliseconds of work per request.

Anything that needs a specific runtime. Most edge platforms run a constrained JavaScript or WebAssembly environment. Your Python dependency with a C extension is not going there.

the architecture that works#

Layered, with each layer doing what it is good at:

edge      → auth check, rate limit, routing, cached content, header work
regional  → application logic, caching, session state
origin    → the database, the writes, the truth

Most requests are answered at the edge from cache. Some go to a regional application tier. Few reach the origin.

That is a CDN with programmability, which is what edge computing actually is, and framing it that way produces much better decisions than framing it as "serverless everywhere."

the thing to measure first#

Before adopting any of this: where does your latency actually go?

Break down a typical request:

• DNS
• TLS handshake
• Network round trip
• Time to first byte at origin
• Origin processing
• Database time within that
• Response transfer

If origin processing is 400 ms and network is 40 ms, moving compute to the edge addresses 40 ms of a 440 ms problem. Fix the 400 first.

This is the most common reason edge adoption disappoints: it was applied to a latency problem that was not a network problem.

the honest summary#

Edge is a very good CDN with programmability, and that is genuinely valuable — it lets you do real work at the perimeter that used to require an origin request.

It is not a general application platform, and the platforms selling it as one are selling the constraint as a feature.

Use it for the perimeter. Keep your data where it can be consistent.

the failure pattern#

1. Platform team forms to reduce duplicated infrastructure work.
2. They build an abstraction over the cloud provider.
3. The abstraction covers 80% of cases well.
4. The remaining 20% is impossible, and the escape hatch is either absent or punished.
5. Product teams work around the platform.
6. Platform team responds by mandating the platform.
7. Everyone is unhappy and the platform is now a tax.

Every step follows from the previous one. The root is step four.

the four properties of platforms that work#

1. An escape hatch that is not punished.

The platform covers the common case. It cannot cover every case, and pretending otherwise is what breaks trust.

There must be a supported path for "I need something the platform does not do," and taking that path must not require an exception process, a meeting, or an apologetic Slack message.

The best platforms make the escape hatch cheap and then compete on being better than it. The worst make it forbidden, which does not eliminate the need — it drives it underground.

2. Adoption is voluntary, at least at first.

A platform that teams choose is a platform that is good. A platform teams are required to use never gets the feedback that would make it good, because the feedback mechanism — people leaving — has been disabled.

If you cannot get voluntary adoption, that is information. Mandating it does not fix the underlying problem; it hides it and converts a product problem into a political one.

Mandate later, when it is genuinely better, and the mandate will be uncontroversial because everyone already uses it.

3. The abstraction leaks deliberately, not accidentally.

Every abstraction leaks. The question is whether you planned for it.

A good platform lets you drop a level when you need to: use the paved path for the deployment, and reach the underlying resource directly when you need something specific. A bad one hides the underlying system entirely, so that when it fails you cannot debug it and neither can the platform team, because now there are two systems to understand.

Concretely: if your platform generates infrastructure configuration, let people see it. If it wraps a cloud API, let people access the underlying resource. If it runs their container, give them the logs from the actual runtime, not a filtered view.

4. The platform team is measured on adoption and satisfaction, not on compliance.

If the platform team's metric is "percentage of services on the platform," they will optimize for mandating it.

If the metric is "would you use this if you had a choice," they will optimize for making it good.

Ask that question quarterly, anonymously, and publish the answer.

the specific things that generate resentment#

Slow escape. A team needs something the platform does not support. The answer is "file a request, we will look at it next quarter." Their deadline is Friday.

Breaking changes without migration paths. The platform is infrastructure. Break it and every team stops. Platform teams frequently hold themselves to a lower compatibility standard than they would accept from a vendor.

Opaque failures. The deploy failed. The error is a platform-internal message. The product engineer cannot debug it and must escalate, which means waiting.

Being a gate rather than a service. A platform that must approve things is a bureaucracy. A platform that makes the right thing easy is infrastructure.

Solving the platform team's problems. Standardization is valuable to the platform team and is not automatically valuable to product teams. If the pitch for a migration is "this makes our lives easier," expect a cool reception.

the framing that works#

You are building a product. Your users are engineers. They have alternatives.

That framing produces the right behaviors automatically: user research before building, documentation that assumes nothing, onboarding that works, support that responds, and a roadmap driven by what users need rather than by architectural preference.

The platform teams I have seen work best behave exactly like a startup selling to a skeptical market, and they say so out loud.

The ones that fail behave like an internal standards body, and they are usually correct about the standards and wrong about how to get them adopted.

the measurement that matters#

Time from "a new engineer joins" to "their code is running in production."

That single number captures most of what a platform is for, it is measurable, and it is the thing product teams actually care about. If it is going down, the platform is working, regardless of what the adoption dashboard says.

Five models. Each works. Each works for a specific kind of project.

1. donations and sponsorship#

Works for: developer-facing tools with a large individual user base and an identifiable maintainer.

Does not work for: libraries deep in a dependency tree, infrastructure nobody knows they use, anything without a personality attached.

The honest arithmetic: donation income correlates with visibility, not with importance. A well-marketed CLI tool with a charismatic maintainer will out-earn a critical cryptography library by a large multiple.

The corporate sponsorship version works better than individual donations and requires the maintainer to do sales, which most maintainers are bad at and hate.

2. foundation governance#

Works for: infrastructure that multiple large companies depend on and that none of them wants a competitor to control.

Does not work for: small projects. The overhead — governance, legal, trademark, process — is substantial, and a foundation with one project and no funded staff is just more paperwork.

The real value of a foundation is not money. It is neutrality: it makes a project safe for competitors to invest in together, which unlocks contribution that would not otherwise happen.

3. dual licensing#

Works for: libraries embedded in other products, where the copyleft obligation is genuinely inconvenient for commercial users.

Ship under a strong copyleft license, sell a commercial license to companies that cannot comply.

Does not work for: anything permissively licensed already (no leverage), anything not embedded (the obligation does not bite), or anything with a permissive competitor of similar quality.

Effective when it fits, and it produces a genuine tension: the license that makes the business work is the one that limits adoption.

4. open core#

Works for: products where enterprise features are genuinely separable from the core — SSO, audit logs, RBAC, compliance reporting, multi-tenancy.

Does not work for: libraries. There is no enterprise tier of a date-parsing library.

The failure mode is well documented: the line between core and commercial moves toward commercial over time, under revenue pressure, and the community that built your adoption watches features they use get moved behind the paywall.

If you do this, write down the line publicly, early, and honor it. "Anything that a single developer needs is open; anything that exists because you have a compliance department is commercial" is a defensible line. Moving it later costs more trust than the revenue is worth.

5. hosted service#

Works for: anything that is annoying to operate. Databases, search, queues, observability, CI.

Give away the software, sell the operation of it. This is the strongest model when it fits, because the value you sell — not having to run it — is real and continuous, and it does not require withholding anything.

The risk: a hyperscaler offers a managed version of your software, at scale, without contributing back. This has happened repeatedly and it is why the source- available licenses exist.

Those licenses solve the problem and cost you the open source designation, which costs you contributors, ecosystem inclusion, and some corporate adoption. It is a real trade with real costs on both sides, and the projects that made it mostly survived, which is the empirical answer to whether it works.

what actually kills projects#

Not the absence of a model. Three other things:

Solo maintainer burnout. One person, unpaid, receiving an unbounded stream of issues, feature requests, and entitled demands. Funding helps and does not fix it — the fix is more maintainers, which is a governance problem.

Success without support. A project that becomes critical infrastructure while its maintainer count stays at one. This is the most dangerous state and it is extremely common.

Corporate abandonment. A company open-sources a project, staffs it with employees, then reorganizes. The external community was never built because it was never needed. Now nobody knows the code.

what companies should do#

If your business depends on open source — and it does — the highest-leverage actions, in order:

1. Pay maintainers of your critical dependencies. Directly. Small amounts to many projects beat large amounts to a few.
2. Assign employee time to upstream contribution. More valuable than money and much rarer.
3. Do not send compliance questionnaires to volunteers. They owe you nothing and the license says so.
4. When you fix a bug in a vendored dependency, upstream it. The number of companies carrying private patches for bugs everyone has is enormous.

None of that requires a strategy document. It requires someone with budget deciding it matters, which is the actual bottleneck.

The first part will recover. The second part is a mistake, and it is the kind of mistake that is invisible for four years and then extremely expensive.

the argument for not hiring juniors#

Stated honestly, because it is not stupid:

A junior engineer's first-year output is mostly small, well-specified tasks — the CRUD endpoint, the test coverage, the bug in a file someone pointed them at. That work is now substantially automatable. Meanwhile the junior requires mentoring time from senior engineers, which is the scarcest resource.

So the ROI on a junior looks worse than it did. That reasoning is coherent.

why it is wrong#

Seniors come from juniors. There is no other supply. An organization that hires only seniors is free-riding on other organizations' training, and if everyone does it, the pipeline empties. This is a classic collective action failure and the industry is walking into it with open eyes.

The judgment that makes seniors valuable comes from doing the work. The ability to look at plausible code and know it is wrong comes from having written the wrong version and debugged it at 3 a.m. You cannot read your way to it and you cannot prompt your way to it.

If the apprenticeship stops, the next generation of senior engineers does not exist, and the current one retires.

Juniors are better at the new tools. Consistently, in my experience. They have no prior workflow to defend and they explore. A team of only senior engineers adopts new tooling slowly and grudgingly.

Mentoring makes seniors better. The engineer who has to explain why a design is wrong understands it better afterward. Teams with no juniors lose that forcing function and get sloppier about articulating their own reasoning.

what actually has to change#

The old model — hire a junior, give them small tickets for a year, gradually increase scope — does not work as well when the small tickets are automated. The model has to change, not the hiring.

Start them on reading, not writing. Give a new engineer a real system and a week to understand and explain it. Have them write the architecture document that does not exist. This builds the skill that actually matters now and it produces something useful.

Give them debugging, not features. Debugging is the skill that generalizes, that AI is least reliable at, and that cannot be learned from a course. Pair them on incidents. Give them the flaky test nobody wants.

Make them review agent output. Reviewing machine-generated code with a senior engineer walking through what is wrong with it is an extraordinarily efficient teaching mechanism. You get a stream of plausible-but-flawed code, which is exactly the training material you want and which used to be expensive to produce.

Require them to write the tests first. Specifying behavior before implementing teaches design, and it is the part of the workflow that has become more important rather than less.

Do not let them delegate the hard part. For the first year, some things get done by hand, deliberately, because the point is the learning rather than the output. Say this out loud so it does not feel like an arbitrary restriction.

the hiring signal that works now#

Traditional junior screens — implement this algorithm, complete this take-home — are substantially defeated and were never good predictors anyway.

What works better:

A code review exercise. Give them a pull request with three problems. Watch what they find and how they talk about it. This is the job.

A debugging exercise on a real repository. Failing test, thirty minutes, any tools they want including AI. Watch the process, not the outcome. Do they read the error? Form a hypothesis? Check it? Notice when the model's suggestion is wrong?

A conversation about something they built. Follow-up questions until you hit the edge of their understanding. Where that edge sits, and how they handle reaching it, tells you almost everything.

the case to make internally#

If you are arguing for junior headcount:

The cost of a junior is roughly a senior's partial attention for a year plus a below-market salary. The cost of a senior hire in three years, in a market where nobody trained anyone, is going to be considerably higher than it is now.

Every organization that stopped training in 2009 spent 2013 through 2016 paying enormous premiums for the engineers who had been trained elsewhere. It is the same trade and it is being made again.

The organizations that keep training through this period will have a meaningful advantage in five years, and it will be very hard to catch up to them quickly.

Three distinct things wear the label. They have different causes, different costs, and different correct responses.

1. deliberate debt#

You knew the better solution. You chose the faster one on purpose, for a reason.

"We are hard-coding this to hit the deadline. We will parameterize it in Q3."

This is the original meaning of the metaphor and it is a legitimate engineering tool. Borrowing against future effort to ship now is frequently correct, especially when you are not yet sure the thing will survive.

The failure is not taking on the debt. It is not recording it.

What makes deliberate debt manageable:

• A comment at the site, explaining the trade-off and the condition that would trigger the fix.
• A ticket, linked from the comment.
• A named condition: "when we have more than five customers on this path" is much better than "later."

# DEBT: hardcoded to the US tax table to ship for the March launch.
# Parameterize when we take our first non-US customer. See ENG-4417.
TAX_RATE = 0.0725

That comment costs thirty seconds and it is the difference between debt and mystery.

2. accidental debt#

You did not know better at the time. The requirements changed. The library you chose turned out to be wrong. The abstraction fit the problem you had and not the one you have now.

This is the largest category and it is not anyone's fault. It is the natural consequence of building things under uncertainty.

The response is refactoring as part of ordinary work, not as a project.

The practice that works: when you touch a file, leave it slightly better. Not a rewrite — rename the confusing variable, extract the function that is doing two things, delete the dead branch. Small, continuous, in the same commit as the feature.

Refactoring projects — a quarter dedicated to cleanup — mostly fail. They are unfunded after the first month, they conflict with in-flight work, and they produce large risky changes with no user-visible benefit to justify them.

Continuous small improvement compounds and is nearly invisible in the process. That is the whole trick.

3. structural debt#

The architecture is wrong for what the system now does.

The monolith needs to be split, or the microservices need to be merged. The data model does not represent the domain. The synchronous design cannot support the scale. The framework choice from 2018 is blocking everything.

This is the expensive category and it is qualitatively different from the other two, because you cannot fix it incrementally without a plan. Small improvements to a wrong structure make the wrong structure more entrenched.

The response is a real project, with a real justification, sized honestly.

That requires:

• A specific cost statement. Not "the architecture is bad." "Every new feature in this area takes three times as long as an equivalent feature elsewhere, and here are the last four examples with dates."
• A specific benefit. What becomes possible or fast afterward.
• A path with intermediate value. A twelve-month rewrite with no deliverable until month twelve will be cancelled in month seven. Structure it so each phase ships something.
• A strangler pattern, not a rewrite. Build the new alongside the old, migrate incrementally, delete the old. Big-bang rewrites have a well-documented failure rate and the reason is always the same: the old system's behavior includes a decade of undocumented edge cases nobody enumerated.

how to talk about it#

The conversation that fails: "we need to spend time on technical debt."

The conversation that works: "the last four features in the billing area each took about three weeks. Equivalent features elsewhere take one. The difference is the data model, specifically that subscriptions and invoices share a table. Fixing it is about six weeks and would bring billing features back to normal velocity. We have eleven billing features on the roadmap."

The second version has: a measurement, a cause, a cost, and a payback period. It is a business case, and business cases get funded.

The first version is a complaint, and complaints do not.

the thing nobody says#

Some debt should never be paid.

Code in a system that will be retired, or that nobody has changed in three years, or that works and has no pending requirements — leave it. Ugly code that is stable and unmodified costs you nothing. It is not debt if you never pay interest on it.

The question is never "is this code good." It is "is this code costing us anything." A lot of what gets called technical debt is code that offends someone's taste in a module nobody touches, and refactoring it is a hobby, not engineering.

It is also, for a majority of the teams running it, a substantial amount of complexity in exchange for benefits they do not receive, and saying so is still mildly heretical.

the problem it actually solves#

Kubernetes was built for: many services, many teams, heterogeneous workloads, on a fleet of machines, where you want bin-packing efficiency and declarative self-healing, and where the platform is operated by people whose job that is.

If you have all of those, it is the right answer and there is no close second.

what it costs#

A permanent learning tax. Pods, deployments, services, ingresses, configmaps, secrets, persistent volume claims, storage classes, service accounts, roles, network policies, resource quotas, and a YAML dialect for each. Every engineer who deploys anything must learn a meaningful fraction of it.

Operational surface. Control plane upgrades, node upgrades, CNI plugin, CSI driver, ingress controller, cert manager, metrics server, log shipper. Each is a component that can break and that must be upgraded on someone else's schedule.

Debugging distance. "Why is my service not reachable" has a dozen possible answers across five layers, and diagnosing it requires understanding all of them.

Cost, frequently. A managed control plane plus nodes sized for the platform's own overhead plus the observability stack it needs is often more than the equivalent capacity on simpler infrastructure.

Resume-driven adoption. This is real and worth naming. Kubernetes on your CV is worth money. That is a genuine incentive pointed away from the simplest solution that works.

the honest threshold#

You probably want Kubernetes if:

• More than roughly fifteen to twenty distinct services, deployed independently.
• More than a handful of teams that need to deploy without coordinating.
• You have someone whose job includes operating the platform, not as a side task.
• Genuinely heterogeneous workloads with different scaling characteristics.
• Multi-tenancy requirements with real isolation needs.

You probably do not if:

• Under ten services.
• One or two teams.
• Nobody owns the platform.
• Traffic is predictable.
• You are running one application with a database.

what to do below the threshold#

The options are better than they were, and all of them are boring:

A platform-as-a-service. Push code, it runs. This is the correct answer for a very large number of applications and the reason people avoid it is usually aesthetic.

Containers on a managed container service without the orchestrator — the various "run this container, scale it, load balance it" products every cloud offers. You get containers, autoscaling, and rolling deploys without the platform.

A couple of servers and a process manager. Systemd units, a reverse proxy with automatic certificates, and a deploy script. This runs an enormous amount of traffic, is trivially debuggable, and every engineer already understands it.

Docker Compose on one machine. For staging, for internal tools, for anything where a single host is enough. Unfashionable, works.

the migration-path argument#

"We will need Kubernetes eventually, so we should start now."

This is the most common justification and it is usually wrong, for two reasons.

First, the complexity cost is paid every day from now until then, and "eventually" frequently never arrives.

Second, containerizing your application is the actual hard part of a future migration, and you can do that without an orchestrator. A containerized application running under a simple process manager can move to Kubernetes later in a couple of weeks.

Build the container. Skip the platform until you have the problem it solves.

the position I will defend#

The teams I have seen most successfully run Kubernetes are large organizations with dedicated platform teams, where it is genuinely the right tool.

The teams I have seen most damaged by it are small ones where a single engineer set it up, that engineer left, and the remaining team is operating a system nobody understands and is afraid to touch.

That second failure is common, expensive, and entirely predictable from the staffing at adoption time. If nobody's job is going to be operating the platform, you should not have a platform.

This is not a controversial position anymore, which is itself notable, because a decade ago it was.

what it absorbed#

The reason the argument ended is that Postgres kept adding the things people left it for:

JSON. jsonb with indexing, operators, and path queries. The document database use case — schemaless-ish data with nested structure — is handled well enough that the specialized option is rarely worth a second system.

Full-text search. Built in, with ranking, stemming, and index support. Not as good as a dedicated search engine at large scale or with complex relevance requirements. Good enough for the search box on most applications, and one fewer system to operate.

Vector search. pgvector with HNSW indexing. Again: not the best available at extreme scale, and entirely adequate for most retrieval workloads, with the enormous advantage that your vectors sit next to your metadata and you can filter and join in one query.

That last point is underrated. A dedicated vector database that cannot join to your relational data means you do the join in application code, badly.

Time series. Partitioning, BRIN indexes, and extensions cover a lot of the use case.

Geospatial. PostGIS remains the best geospatial implementation in any database, period.

Queues. SELECT ... FOR UPDATE SKIP LOCKED gives you a correct, transactional job queue in about twenty lines. For anything under high-thousands of jobs per second — which is most systems — you do not need a dedicated queue, and the transactional property (enqueue in the same transaction as the state change) removes an entire class of consistency bug.

the operational reality#

One system to operate. Every additional datastore is a backup strategy, a monitoring setup, an upgrade path, a failure mode, an on-call runbook, and a set of consistency questions between it and everything else.

The cost of a second datastore is not the license. It is the permanent operational surface, and teams consistently underestimate it by a large factor.

Transactions across your data. If your users and your documents and your embeddings are in one database, a change to all three is one transaction. Split across three systems, it is a distributed consistency problem you now own.

when it is genuinely wrong#

Being honest about this matters, because "just use Postgres" as a reflex is the same failure mode as any other reflex.

Extreme write throughput on a single logical dataset. Postgres scales writes vertically, well, up to a point. Past that point you need sharding, and Postgres's sharding story is real but less mature than systems designed for it from the start. If you genuinely need millions of writes per second, look elsewhere.

Analytical queries over very large datasets. Postgres is a row store. Scanning a billion rows to compute an aggregate is what column stores are for, and the difference is orders of magnitude. Use a column store — several integrate cleanly with Postgres.

Global multi-region with low write latency everywhere. Postgres replication is primary-based. If you need writes accepted in multiple regions with low latency, that is a distributed database problem and Postgres is not one.

Extremely high-volume caching. Redis exists and is better at being a cache. This is a legitimate second system.

Embedded / on-device. SQLite. Different problem, different answer.

the thing to actually do#

Start with Postgres. Put everything in it. Measure.

When something is genuinely the bottleneck — and you will know, because you will have the metrics — extract that one thing to a specialized system with a clear reason.

That order matters. Teams that start with five specialized systems on the theory that they will need them end up operating five systems for a workload one would have handled, and the complexity is permanent.

the version note#

Whatever you are running, be less than two major versions behind. Postgres's release quality is high, the upgrades are usually boring, and the performance improvements between versions are substantial and free.

The people who have bad Postgres upgrade experiences are the ones who skipped four versions and tried to do it in one jump during an outage.

Several things changed and the answer is now more nuanced than the reflex suggests.

what changed in favor of self-hosting#

Machines got enormous. A single server you can rent for a few hundred dollars a month has more cores, more memory, and dramatically more I/O than a rack of hardware from 2012. A very large number of applications fit on one machine with room to spare.

The tooling got good. Configuration management, container runtimes, reverse proxies with automatic certificates, backup tooling. What required a team a decade ago requires a competent person and a weekend.

Cloud egress pricing did not fall. Compute prices came down. Bandwidth pricing at the major clouds is still a large multiple of what it costs, and for bandwidth-heavy applications it dominates the bill.

Managed service prices are high relative to the alternative. A managed database costs several times what the equivalent instance costs, for operational convenience that is real and is not always worth the multiple.

what changed against it#

Security expectations rose. Patching, hardening, monitoring, incident response. Self-hosting means you own all of it, and the threat environment is worse than it was.

Compliance frameworks assume cloud controls. SOC 2, ISO 27001, and their relatives are achievable self-hosted and the evidence collection is more work.

The talent assumption inverted. A decade ago every team had someone who knew Linux systems administration. Now a lot of teams do not, and hiring for it is harder than hiring for cloud skills.

the honest decision framework#

Self-host when:

• Your workload is steady rather than spiky. Cloud's core value proposition is elasticity, and you are paying for elasticity you do not use.
• Bandwidth is a large share of your bill.
• You have or can hire operational competence.
• Data locality or sovereignty is a requirement.
• You are at a scale where the cloud premium is a meaningful number — which starts lower than most people assume.

Use the cloud when:

• Traffic is spiky or unpredictable.
• You are early and optimizing for speed of iteration over unit economics.
• You need global presence and do not want to operate it.
• Your team's time is better spent on the product, which for most early-stage companies it is.
• Compliance requirements are easier to satisfy with a provider's attestations.

The hybrid that most people should consider: run the steady baseline on owned or rented hardware, burst to cloud for peaks, keep object storage and CDN with a provider. This captures most of the cost advantage without giving up elasticity where it matters.

the middle option nobody talks about#

Between "hyperscaler" and "rack in a colo" there is a large market of dedicated server providers and mid-size clouds: a real machine, in a real datacenter, with network and power handled, for a monthly fee.

You get root, predictable performance without noisy neighbors, and bandwidth allowances that are not priced as a profit center. You do not get managed databases, autoscaling, or a hundred adjacent services.

For a very large number of applications this is the correct answer and it is under-considered because the discourse is binary.

the operational minimum#

If you self-host, these are non-negotiable:

• Automated, tested restores. Not backups — restores. A backup you have never restored is a hypothesis. Test it quarterly, on a schedule, with a timer running.
• Unattended security updates, at least for the OS.
• Monitoring with alerting that reaches a human. Disk full is the most common self-hosted outage and it is entirely preventable.
• Infrastructure as code. The machine must be reproducible. If rebuilding it requires someone's memory, you have a single point of failure that is a person.
• A documented runbook for the failures you expect: disk, certificate expiration, service crash, host failure.

That is a weekend of setup and a few hours a month. If nobody on the team will own those hours, use the cloud — that is a legitimate reason and it is the actual deciding factor more often than cost is.

the thing that changed my mind#

I used to treat "we run our own servers" as a red flag. I now treat "we are on the cloud and have never modeled the alternative" as an equal one.

Both are defaults applied without analysis. The analysis takes an afternoon and the answer is frequently not what the reflex says.

That understates it by a large factor, and the reason is the same reason context switching is expensive for a CPU.

the fragmentation cost#

Deep engineering work requires holding a system in your head: the call graph, the invariants, the specific thing you were about to check, the four hypotheses you had narrowed to two.

Building that state takes time — call it twenty to forty minutes for nontrivial work. Losing it takes one interruption.

So a meeting at 2 p.m. does not cost thirty minutes. It costs:

• The twenty minutes before it, where you cannot start anything substantial because you will be interrupted.
• The thirty minutes of the meeting.
• The twenty to forty minutes after it, rebuilding the state you lost.

That is roughly ninety minutes for a thirty-minute meeting, per person, and it is the optimistic case.

Worse: a meeting placed in the middle of a morning does not remove ninety minutes from a four-hour block. It removes the block. Two ninety-minute fragments are not equivalent to one three-hour stretch, because the hardest work requires depth that ninety minutes cannot reach.

the schedule shapes that work#

Meeting-free days. Two full days a week with no recurring meetings. Not "try to keep them clear" — a calendar policy. This is the single highest-impact scheduling change available and it is nearly free.

Meetings at the edges. Cluster them at the start or end of the day. A day with three meetings from 9 to 11 and nothing after is dramatically more productive than one with three meetings at 10, 1, and 3.

Default to 25 and 50 minutes. Not 30 and 60. The buffer prevents the cascade where every meeting starts late and the person coming from the previous one misses the first five minutes.

Async by default for status. Standup is a meeting to exchange information that could be a written update. The argument for synchronous standup is that it surfaces blockers, which it does, and a written update with a "blocked on" field surfaces them too, in a searchable form, without costing everyone their morning.

when meetings are actually right#

They are, frequently, and the anti-meeting position overcorrects.

High-bandwidth disagreement. Two people who disagree about a design will resolve it in twenty minutes of conversation and in nine days of comment threads. Real-time is enormously better for anything with back-and-forth.

Ambiguity resolution. When nobody is sure what the problem even is, a conversation converges much faster than writing, because you can ask the clarifying question immediately.

Anything with emotional content. Feedback, conflict, bad news. Writing is the wrong medium and using it is usually avoidance.

Building relationships. Real, unmeasurable, and the reason fully-async organizations struggle in ways they cannot diagnose.

The rule: meet for things that require interaction. Write for things that require information.

the tests#

Before scheduling, three questions:

What decision will be made? If none, this is a status update. Write it.

Who must be there for that decision? The answer is usually two to four people. Everyone else can read the outcome.

What would happen if we did not have it? If the answer is "nothing," you have found a recurring meeting that outlived its purpose. Every organization has several.

the audit worth doing#

Take a recurring meeting and cancel it for a month. Not "make it optional" — cancel it.

If someone notices and asks for it back, with a reason, reinstate it. Most of the time nobody notices, which tells you what you needed to know.

This works because recurring meetings are created for a reason that expires and never re-evaluated, and the social cost of proposing cancellation is high enough that nobody does it. A trial cancellation removes the social cost.

the part managers should hear#

Your calendar is not your team's calendar. A manager's day is legitimately made of meetings — that is the job, and thirty-minute chunks are the natural unit.

An engineer's day is not, and scheduling as if it were is the single most common way well-meaning managers destroy their team's output while looking at metrics that do not show it.

Protect the blocks. It is most of what schedule-level management can do.

Both failures come from the same mistake: treating "no" as a verdict rather than as the opening of a conversation about trade-offs.

what the request actually is#

When someone asks you to build something, they are not asking for the thing. They are asking for an outcome, and the thing is their guess at how to get it.

That means the highest-value response is frequently not yes or no. It is a better guess.

"You are asking for a real-time dashboard. What decision are you going to make from it? If it is 'should we page someone,' an alert is better than a dashboard and it is a day of work instead of a month."

That is a no to the request and a yes to the outcome, and nobody experiences it as obstruction.

Ask what the outcome is before you evaluate the request. Half the time the request evaporates.

the four honest noes#

"Not this, that." The alternative approach that achieves the same outcome for less. This is the best one and it requires actually understanding the problem.

"Yes, and here is what it displaces." Not a no. A statement about capacity, which is factual and is the other person's decision to make.

"I can do that in this cycle. It means the API migration slips to next quarter. Which do you want?"

This is enormously more effective than "we do not have time," because it hands the prioritization decision to the person whose job it is, with the information they need.

"Yes, after X." A sequencing objection. "We can build this on top of the new data model. Building it on the old one means we build it twice."

"No, and here is the risk I am flagging." The real no, reserved for correctness, security, legal, or ethical problems. Use it rarely so that it lands when you do.

"I am not going to implement this the way it is specified because it stores plaintext credentials. I will implement it with a token exchange, which takes three extra days. If that is unacceptable, I want the decision documented and made by someone who can accept the risk."

That is a hard sentence to say and it is the sentence the job sometimes requires.

the ones that do not work#

"That is not possible." Almost always false, and the person will find someone who says it is. Say "that would take six months" instead, which is the real constraint and is checkable.

"That is a bad idea." Without an alternative, this is just friction.

Silence. Not responding is a no that damages trust, because it looks like you did not care rather than that you disagreed.

"Sure" followed by not doing it. The worst one. It destroys your reliability, which is the only currency you actually have.

the timing#

Say no early. The cost of a no rises with every day of planning that assumed a yes.

An objection raised in the design review is a discussion. The same objection raised two weeks before launch is a crisis, and people will remember that you could have said it earlier — correctly.

If you have doubts, voice them while they are cheap.

the part about capital#

Every no spends something. Every yes earns something. If you never say yes, your noes stop landing, because you have become the person who says no.

Deliver reliably on what you agree to. That is what makes the refusal credible when it matters. Engineers who are trusted to ship get enormous latitude to push back, and engineers who are not, do not — regardless of whether they are right.

the hardest case#

Sometimes you are overruled on something you believe is wrong, and it is not a correctness or ethics issue — it is a judgment call and someone with the authority made a different one.

Disagree and commit is the right practice here and it is genuinely hard. Say your piece once, clearly, in writing. Then build the thing well.

Do not build it badly to prove a point. Do not relitigate it in every standup. Do not say "I told you so" if it goes wrong — the written record already said it, and gloating costs you the ability to be listened to next time.

You will be wrong about some of these. That is the actual reason to commit gracefully: you are not always right, and a culture where disagreement is followed by good-faith execution is one where being wrong is survivable for everyone, including you.

That pause is the entire problem.

the four kinds, and why mixing them fails#

The taxonomy that fixed documentation for me — and it is not mine, it is the Diátaxis framework — is that there are four distinct kinds and they have incompatible goals.

Tutorials teach a beginner by having them do something that works. The goal is a successful experience, not completeness. A tutorial that mentions every option has failed. It should be prescriptive, opinionated, and it should work exactly as written, every time.

How-to guides help someone accomplish a specific task they already understand. "How to configure TLS." Goal-oriented, assumes competence, skips explanation.

Reference describes the machinery precisely and completely. Every parameter, every return value, every error. Boring by design. Generated where possible.

Explanation provides understanding. Why is it designed this way? What are the trade-offs? What is the mental model? This is the kind that is almost always missing and the kind that most reduces support burden.

Most documentation fails because it tries to be all four at once. A tutorial that stops to explain architecture loses the beginner. A reference page with a narrative is hard to scan. Separate them, label them, and each one gets better.

what "staff it like a product" means#

One named owner. Not "the team." A person whose review includes it.

A budget in the sprint. Documentation work sized and scheduled alongside features, not appended to the end of a ticket where it gets cut.

Metrics. Support tickets that a doc would have prevented. Search queries with no results. Time-to-first-successful-request for a new user. Page-level feedback. Every one of these is measurable and almost nobody measures them.

A definition of done that includes it. A feature is not shipped until it is documented. This is either enforced or it is a slogan; there is no middle.

the practices that actually move the needle#

Docs live with the code. Same repository, same pull request, same review. Documentation in a separate wiki drifts within one quarter, guaranteed, without exception.

Test the examples. Every code sample in your docs should be extracted and run in CI. Broken examples are worse than no examples — they destroy trust in the whole document, and every set of docs has them, because they were correct when written.

Write the failure cases. The single highest-value section in any documentation is "common errors and what they mean." This is what Stack Overflow existed to provide and it is the thing your docs almost certainly lack.

Go read your support queue. Every recurring question is a documentation gap with a measured frequency attached.

Date and version everything. "This page describes v4.2, last updated 2026-01-15." Undated documentation is untrustworthy documentation, because the reader cannot tell whether it is current.

Make the first example work. The single most common documentation failure: the quickstart does not run. Someone changed a default, renamed a parameter, required a new config field. Test the quickstart in CI, on a clean environment, on every release.

the argument that gets budget#

Documentation is deflection. Every question answered by a doc is a question not asked of an engineer.

Count your support load. Estimate the fraction that is documentation-shaped — "how do I," "what does this error mean," "does it support." In most organizations it is more than half.

Now price that in engineer-hours. That is your documentation ROI, and it is usually large enough to fund a technical writer, which is the actual right answer and which almost nobody does.

the new reason it matters#

Your documentation is now also a model's training data and a model's retrieval corpus.

When a developer asks an assistant about your library, the answer is synthesized from your docs. If your docs are wrong, incomplete, or ambiguous, the assistant confidently produces wrong code, and the user blames your library.

You have less control over how your project is explained than you did three years ago, and the only lever you have is the quality of the source material.

That is a strange new incentive and it is the strongest argument for good documentation that has ever existed.

The pattern is consistent enough to be predictive, which makes it worth naming.

wave one: fine-tuning#

The thesis (2023): general models are generic. Fine-tune on your domain data and you get a model that is specifically good at your problem and that competitors cannot replicate.

What happened: base models improved faster than fine-tunes could keep up. A fine-tuned model from six months ago was worse than the new base model with a good prompt. Every fine-tune had to be redone on every model release, which is a treadmill.

Where it settled: fine-tuning is genuinely valuable for narrow, stable, high-volume tasks — classification into your specific taxonomy, output in your specific format, a small model matching a large model's behavior on one task. It is not a moat and it is not a product strategy.

wave two: RAG#

The thesis (2023-24): the model does not know your data. Build a retrieval pipeline — chunk, embed, index, retrieve, rerank — and you have a defensible system built on proprietary knowledge.

What happened: context windows grew by two orders of magnitude, long-context quality improved, and prompt caching made large contexts economical. A large fraction of naive RAG got replaced by putting the documents in the prompt.

Simultaneously, the pipeline components commoditized. Embedding models became interchangeable. Vector search became a feature of every database rather than a product.

Where it settled: retrieval did not go away. It moved. Retrieval is now a tool the model calls rather than a preprocessing step, and it is genuinely necessary at large corpus sizes, where citation is required, and where cost or latency rules out large contexts.

The infrastructure repositioned rather than dying, which is what usually happens.

wave three: agent frameworks#

The thesis (2024-25): models cannot plan reliably. Build the orchestration — task decomposition, tool routing, retry logic, state management — and own the layer that makes agents work.

What happened: the models absorbed it. In-context tool use during reasoning removed the need for an external loop. Native parallel tool calling removed the need for a dispatcher. Memory tools and context editing removed the need for external state management.

Each capability the framework provided became a model feature within about a year.

Where it settled: in progress, but the shape is clear. Orchestration frameworks are converging on thin conveniences. The durable parts are evaluation, observability, and the domain-specific policy that no model will ever have.

the pattern#

Every wave follows the same arc:

1. The model has a limitation.
2. Companies build infrastructure to work around the limitation.
3. The limitation gets fixed in the model.
4. The infrastructure either finds a new position or disappears.

The consistent error is building on a gap rather than on an asset. A gap is temporary by construction — the labs are actively working to close it, with more resources than you have.

what has actually been durable#

Across all three waves, the same things kept their value:

Proprietary data. Not "we have documents" — everyone has documents. Data that is genuinely yours: production logs, customer interactions, labeled outcomes, domain expertise encoded as examples. Nobody can buy it and no model was trained on it.

Evaluation specific to your task. The company that knows, precisely, how well a system performs on their actual problem can adopt a new model in a day. The one that does not spends a month on vibes. That gap compounds every release cycle.

Distribution and workflow integration. Being where the user already works. The most boring answer and the most durable.

Domain constraints. The rules, regulations, edge cases, and institutional knowledge that make a generic capability into a usable product. This is unglamorous and it is the actual work.

Trust. Security posture, compliance, reliability, support. Enterprises buy this and it takes years to build.

the test to apply#

Before building on top of a model limitation, ask: if this limitation disappeared next quarter, what would I have left?

If the answer is "nothing," you are building a bridge over a river that is being drained.

If the answer is "the data, the evaluations, the integrations, and the customer relationships," build it, and expect to throw the bridge away.

The pendulum framing is unhelpful. What is useful is naming the specific reasons the original argument was wrong, because those reasons generalize.

what the case for microservices actually was#

Four claims, all plausible:

1. Independent deployment. Teams ship without coordinating.
2. Independent scaling. Scale the busy part, not everything.
3. Technology freedom. Each service picks its own stack.
4. Fault isolation. One service's failure does not take down the rest.

how each one went#

Independent deployment: real, and the main benefit. This one held up. If two teams can deploy without coordinating, that is genuinely valuable and it scales with organization size.

The catch: it requires the services to be genuinely independent. If service A cannot deploy without service B deploying a compatible change first, you have a distributed monolith — all the operational cost, none of the benefit. That is the outcome most organizations actually got, because splitting a system along the wrong seams produces services that must change together.

Independent scaling: real and usually irrelevant. Most applications are not scale-constrained in a way where this matters. A monolith on a bigger machine handles a very large amount of traffic, and modern machines are enormous.

Where it matters — one component with wildly different resource requirements, like a video transcoder or an ML inference path — extract that one thing. That is not microservices, that is a service.

Technology freedom: real and a mistake. Six languages means six toolchains, six sets of libraries, six deployment stories, six on-call rotations that cannot help each other, and an engineer who cannot move between teams without a month of ramp-up.

Most organizations that got this eventually mandated standardization anyway, which means they paid the cost and gave up the benefit.

Fault isolation: inverted. This is the one that went most wrong.

In a monolith, a failing component throws an exception. In a distributed system, a failing component times out — after 30 seconds, while holding a connection, in every caller, simultaneously. Cascading failure, retry amplification, and metastable states are failure modes that a monolith simply does not have.

You do not get fault isolation for free by adding a network. You get it by implementing circuit breakers, timeouts, bulkheads, and backpressure — deliberate engineering that most teams did not do because they thought the architecture gave it to them.

the costs nobody budgeted#

Debugging. A single user action touches nine services. Understanding what happened requires distributed tracing, correlated logs, and a mental model of the whole call graph. This is dramatically harder than a stack trace and it is a permanent tax on every incident.

Data consistency. A transaction across services is not a transaction. You get sagas, compensating actions, eventual consistency, and a class of bug where the system is in a state that should be impossible.

Local development. Running the system on a laptop is a project. Teams end up developing against shared environments, which serializes work and reintroduces the coordination cost that microservices were supposed to remove.

Latency. In-process call: nanoseconds. Network call: milliseconds. A chain of nine is a user-visible delay that did not exist before.

Operational surface. Nine services means nine deployment pipelines, nine sets of dashboards, nine on-call runbooks, nine dependency trees to patch.

the synthesis#

Start with a monolith. One deployable, one database, clear internal module boundaries with enforced dependency rules.

Enforce the boundaries in code. This is the part people skip and it is the part that matters. Modules with explicit public interfaces, dependency rules that fail the build, and no reaching into another module's tables. If you do this, you have most of the benefit and none of the network.

Extract a service when you have a specific reason. Good reasons: a genuinely different scaling profile, a team that needs independent release cadence and can have it, a compliance boundary, a component that must be written in a different language.

Bad reasons: it feels cleaner, we read a blog post, our architecture diagram would look better.

The extraction should be easy if the boundaries were real. If pulling a module out is a six-month project, that tells you the boundary was not real, and it also tells you extracting it would not have given you independence.

the general lesson#

Every architectural decision trades one kind of complexity for another. Microservices trade code complexity for operational complexity.

For a large organization with many teams, that is frequently a good trade — operational complexity can be handled by a platform team, and coordination complexity cannot be handled by anyone.

For a team of twelve, it is a terrible trade, and the industry spent five years recommending it to teams of twelve.

the design decision that defines it#

Go's compatibility promise is stronger than almost any language's: code written against Go 1 continues to compile and run. That has held since 2012.

Combined with a deliberate resistance to adding features, the effect is that Go code from 2015 reads like Go code from today. There is one way to do most things. There is no dialect. There is no "modern Go" versus "legacy Go."

For a language used to write infrastructure that must be maintained for a decade by rotating teams, that property is worth more than any individual feature.

what the criticism gets right#

Error handling is verbose. if err != nil is a large share of the lines in a lot of Go code. The proposals to fix it have all been rejected, repeatedly, and the reasoning — that explicit error handling at every call site is a feature, not a bug — is coherent and is genuinely annoying to live with.

Generics arrived late and are limited. No sum types. No method type parameters. The type inference gives up in cases where you expect it to work. Generics in Go are useful and they are clearly a retrofit.

The nil interface trap. A nil pointer stored in an interface produces a non-nil interface. This bites everyone once and it is a genuine wart.

No sum types. The single most requested feature. Modeling "this is one of three things" in Go requires an interface with unexported methods and a type switch, which is neither exhaustive-checked nor pleasant.

what the criticism gets wrong#

The complaints are almost all about expressiveness, and expressiveness is not the thing Go optimizes for. It optimizes for a large team maintaining a large codebase over a long time, with new people joining constantly.

Under that objective function:

• Verbosity is fine if it makes the code obvious without context.
• Few features is good, because every feature is a dialect someone will write in and someone else will have to read.
• Fast compilation matters enormously, because it determines the feedback loop and therefore how people work.
• A good standard library means fewer dependencies, which means fewer supply chain problems and fewer upgrade treadmills.
• gofmt ended formatting arguments permanently, which saved the industry an incalculable number of hours.

Go is not trying to be a good language for writing clever code. It is trying to be a good language for reading code someone else wrote three years ago while you are on call at 3 a.m.

It is very good at that.

the concurrency story, honestly#

Goroutines and channels were revolutionary in 2012 and are now table stakes. Several languages have equivalent or better models.

What has held up: the scheduler is excellent, the tooling around concurrency — the race detector especially — is best in class, and context for cancellation propagation is a good design that most ecosystems lack an equivalent of.

What has not: channels are overused by people who learned Go from the tour. Most Go code should use a mutex and a plain function call. "Do not communicate by sharing memory; share memory by communicating" is good advice that has produced a lot of unnecessarily channel-based code.

where it wins#

Network services, CLI tools, infrastructure daemons, anything deployed as a single static binary, anything with a large team.

The ecosystem effect is real: a very large fraction of the cloud-native stack is Go. If you work in infrastructure, you will read Go whether or not you write it.

where it does not#

Anything needing precise memory control. Anything numeric or scientific, where the ecosystem is thin and the language does not help. Anything where expressiveness genuinely pays — a compiler, a complex domain model, anything with rich algebraic structure.

the thing worth stealing#

Whatever language you use: Go's compatibility promise, its formatting standardization, and its resistance to feature accumulation are choices, not accidents.

Most projects would benefit from adopting the spirit of all three. Pick one way to do things. Automate the formatting argument out of existence. Say no to the feature that adds a second way to express something that already has one.

That is available to you regardless of your language, and it is most of what makes Go codebases pleasant.

Rather than enumerate, it is worth asking what "finished" would look like and how close this is.

what got finished#

The list of "this obviously should work and does not" items has genuinely shrunk. Trait upcasting, let chains, RPIT capture, anonymous pipes, const in more places, SIMD intrinsics, async closures. Each of those was a multi-year open question and each is now just how the language works.

That is the signature of a language moving from the growth phase into the maintenance phase, and it is a good place to be. The compiler is faster than it was. The error messages remain the best in the industry. The tooling story — cargo, clippy, rustfmt, rust-analyzer — is coherent in a way that most languages never achieve.

what is left, honestly#

Async. Still the sharpest edge. Async traits work. Async closures work. What does not work smoothly: cancellation semantics that do not surprise you, async drop, Send bound propagation through generic async code, and the absence of a standard executor interface which fragments the ecosystem.

The Pin API remains the piece of Rust that experienced engineers most often describe as genuinely confusing, and the ergonomic improvements have been incremental.

This is the area where Rust is meaningfully harder than it needs to be, and where a new user is most likely to conclude the language is too complicated. It matters because async is how you write network services, and network services are most of software.

Const generic expressions. [T; N * 2] still needs nightly. The blocker is real — deciding when two type-level expressions are equal is undecidable in general and the team will not ship a rule they cannot explain.

GUI. Ten-plus years, several serious projects, no consensus. Partly a Rust problem: the borrow checker's relationship with the retained-mode widget tree that every traditional GUI framework uses is genuinely awkward. Partly not a Rust problem: cross-platform GUI is unsolved everywhere.

Compile times. Better every year. Still slower than Go. Structurally will remain so, because monomorphization and the optimization Rust performs are not free and are the reason the output is fast.

the adoption picture, unsentimentally#

Won decisively: systems programming, CLI tooling, JavaScript build tooling, cryptography implementations, embedded, WebAssembly targets, kernel drivers in both Linux and Windows.

Winning slowly: backend services, where Go's simplicity and compile speed are a real competitor and where the async ergonomics cost is felt daily.

Not winning and probably will not: application development, data science, scripting. Different constraints, different right answers.

That is a good outcome. A language does not need to win everything, and the places Rust won are the places where memory safety bugs were causing the most damage.

the thing to appreciate#

Eleven years of six-week releases and no broken stable program. Three editions with automated migration and no ecosystem split. A governance structure that has survived real disagreements in public.

For a language that has changed as much as Rust has, that stability record is the actual achievement, and it is the reason people are willing to put infrastructure on it. Features are cheap. Trust is not.

for someone deciding whether to learn it in 2026#

If you write systems software, networking infrastructure, embedded code, or anything where a memory safety bug is a security incident: yes, and you probably already know that.

If you write web applications: the async ergonomics are the thing you will fight, and Go or a good typed scripting language will make you more productive faster. Learn Rust anyway, eventually, because understanding ownership makes you better in every language.

If you tried it in 2021 and bounced off the compile times or the error messages: try again. Both are substantially different now.