The instinct at this point is to hire a “DevOps person” to sit alongside the application developers and handle the plumbing - configure the pipelines, manage the servers, put out the fires. It’s the obvious move. It’s also the wrong one.

I know because I’ve spent twenty years working in small companies at exactly this inflection point. The core argument I want to make is one I first articulated in an internal memo in 2012 and have continued to refine through every role since: your first infrastructure hire should not be someone who does work for your developers. It should be someone who builds the platform that lets them do the work themselves.

Two Kinds of Work

To understand why, it helps to recognize that application developers and platform engineers are motivated by fundamentally different kinds of problems.

Application developers love work that is vertically aligned with the business. They want to build the feature that delights users, implement the workflow that solves a specific customer problem, or optimize the experience that drives conversion. These are point-oriented problems. They require deep understanding of the product, close partnership with design and business stakeholders, and heavy doses of business logic and creative problem-solving. The best product engineering is tightly coupled to business context.

Platform engineers thrive in a world of abstraction and generalization. The problems they gravitate toward are horizontally oriented. They’re most impactful when applied broadly: a deployment framework that works for any service, a CI pipeline that handles any application, a monitoring stack that covers everything. These solutions are deliberately light on business logic. They don’t require deep partnership with individual product verticals. They require an excellent overall understanding of how the system operates - and a talent for anticipating what other people will need before they need it.

When you hire an ops person to sit next to your developers and manage infrastructure on their behalf, you’re asking someone with horizontal instincts to do vertical work. You’re spending platform talent on point problems. It works in the short term, but it doesn’t scale, it doesn’t compound, and it doesn’t leverage either person’s strengths.

The Lego Block Model

The alternative is what I think of as the Lego block model. The platform engineer’s job is to design and build new blocks - tools, frameworks, services, and abstractions - that application developers assemble in creative ways to build product. The platform engineer builds the deployment framework; the developer uses it to ship a feature. The platform engineer builds the CI pipeline; the developer uses it to test and deliver their code. The platform engineer builds the monitoring and alerting layer; the developer uses it to understand the health of what they’ve built.

This is a fundamentally different posture than the traditional ops handoff. Under this model:

The platform engineer’s work is completely horizontal, focused on building technology that is broadly applicable across multiple product efforts. This maximizes the leverage of engineering output - one well-designed abstraction serves every developer on the team.

Application developers get end-to-end ownership of the work they produce. They own the feature from conception through deployment. They own the runtime behavior of their code. They can ship without filing a ticket, without waiting in a queue, without asking permission. They’re accountable for what they build - and they have the tools to meet that accountability.

The platform engineer operates as what I like to call “Tony Stark’s tailor” - building the armor that prevents developers from falling into pitfalls that yield unscalable or unreliable solutions, while never constraining what they can build inside that armor.

The key insight is this: a small company should not optimize its platform for efficiency. It should optimize for autonomy. What you’re offering is clear ownership of ideas and accountability for their delivery. These are roles that allow for quick movement, eliminate the need for unnecessary consensus, and open the door to the kind of velocity that small companies need to survive.

What This Looks Like in Practice

The expectation is not that application developers suddenly become infrastructure experts. Nor is it that the platform engineer will be ignorant of business logic and product initiatives. A partnership is inherent to the success of this model. In the absence of mature abstractions, the platform engineer partners with developers to create solutions - but not in the form of a handoff. The engineering challenge is to build self-service components such that developers can iterate autonomously on the product logic that delivers their ideas to users.

After the initial rollout of a solution, the ownership lines are clear. The platform engineer owns the infrastructure they build. The developers own the application code and business logic they provide. No form of tight coupling is required to iterate.

For this to work well, the platform engineer needs to be working a few steps ahead. The production from an infrastructure team deployed this way should look like magic to the developers - things fall into place because their needs have been anticipated, and the scaling and resilience concerns have already been addressed at the platform level.

This Applies Double for Data Teams

Everything I’ve described about the application developer relationship holds - and then some - when a company starts investing in data science.

Data scientists are, if anything, even more vertically oriented than application developers. They set out to optimize a particular process, build a predictive model for a specific use case, or reimagine how a part of the business operates. Their work requires deep partnership with business verticals, a heavy mix of business logic, and a healthy dose of creativity. The best outcome of their efforts is often an artifact meant for a machine consumer rather than a human one - an algorithm or API that fundamentally changes the operation of the business.

And yet data scientists are typically not classically trained software engineers. This is historically why ETL work, pipeline development, and production deployment have been handed off to engineers in assembly-line fashion. But all of those tasks are inherently vertical - they’re point-focused work tied to a specific data science initiative. The assembly line wastes engineering talent on work that doesn’t compound.

The Lego block model fits naturally. The platform engineer builds the ETL framework; the data scientist uses it to construct a specific pipeline. The platform engineer stands up experiment tracking and model versioning; the data scientist uses it to manage their work from notebook to production. The platform engineer configures the model serving infrastructure; the data scientist deploys against it. The data scientist should be able to develop and deploy without asking permission from engineering, be accountable for support, and be held to the same performance and reliability requirements as any other production code.

The armor just needs to be a little thicker. Data scientists need more guardrails than application developers, not because they’re less capable, but because the failure modes of data infrastructure are less visible and the consequences of unscalable solutions compound quietly. The tailor’s job is to make those guardrails feel like freedom.

The Tooling Landscape Has Caught Up

When I first articulated this model in 2012, the tooling to support it existed but required significant custom engineering. Today, the ecosystem makes this approach dramatically more accessible for small teams.

For application developers: Container orchestration, infrastructure-as-code, and CI/CD have matured to the point where a single platform engineer can provide a production-grade developer experience. Docker and managed container platforms handle the runtime. GitHub Actions or similar tools handle the build and deployment pipeline. Infrastructure-as-code tools like Terraform or Pulumi make provisioning reproducible and self-service. The platform engineer’s job is to assemble these into a coherent, opinionated stack that developers interact with through simple configuration and convention - not tickets.

For data teams: dbt has become the standard for analytics engineering - we were using it at Kickstarter in 2017, which was forward-looking at the time, but today it’s table stakes. Modern orchestrators like Dagster and Prefect have replaced the older generation of workflow tools with frameworks that are far more intuitive to configure and operate. MLflow has emerged as the de facto open-source platform for managing the ML lifecycle: experiment tracking, model packaging, versioning, and deployment. It’s lightweight enough to self-host on a single server backed by PostgreSQL and cloud storage, yet comprehensive enough to give data scientists a self-service path from experimentation to production. For teams already on a cloud provider, managed ML platforms like AWS SageMaker, Google’s Vertex AI, or Azure ML offer similar capabilities with less operational overhead.

Across both: Observability and monitoring tools - Datadog, Grafana, the cloud-native equivalents - have become accessible enough that a platform engineer can build a monitoring layer that serves both application developers and data scientists. The same is true for data quality tooling, alerting, and incident management.

The net effect: the Lego blocks are better than they’ve ever been. The role of the platform engineer has shifted from building everything from scratch to assembling, configuring, and operating a coherent platform from high-quality components - and then getting out of the way.

The Case for the Hire

If you’re a small company at this inflection point - product-market fit achieved, team growing, infrastructure groaning - the question isn’t whether to invest in platform engineering. It’s what kind of investment to make.

The ops-as-service model - hire someone to manage infrastructure on behalf of your developers, one task at a time - feels safe and incremental. But it creates dependency, limits autonomy, and spends engineering talent on work that doesn’t compound.

The platform model requires a different kind of hire: someone who thinks horizontally, who understands abstraction and leverage, who can anticipate what developers will need before they need it, and who measures their success not by the tickets they close but by the tickets that never get filed. Someone whose goal is to make themselves invisible - to build the infrastructure so well that the people using it forget it’s there.

That is the work I find most satisfying. It’s the work I’ve spent twenty years learning how to do. And it’s the work that, for a small company at the right inflection point, creates the most lasting value.

It isn’t. It’s an economic system. Those are different things, and the confusion between them is doing real damage.

Capitalism is exceptionally good at one specific thing: allocating scarce resources through price signals and voluntary exchange. It’s a mechanism, and it’s an elegant one. When you need to figure out how to distribute limited goods and coordinate millions of individual decisions, capitalism is probably the most efficient tool humanity has invented.

But somewhere along the way, we stopped talking about capitalism as a tool and started talking about it as a morality. We built narratives that said: those who accumulate wealth deserve it. Those who don’t are lazy or incompetent. The market rewards virtue and punishes vice. Profit is the measure of value. Efficiency is the highest good.

These aren’t true. They’re moral stories we’ve layered on top of an amoral mechanism. And we’ve done it so thoroughly that most people can’t distinguish between the mechanism and the mythology anymore.

The Amoral Nature of Capitalism

This needs to be stated clearly: capitalism doesn’t care about human flourishing. It doesn’t care about justice, beauty, community, care, or meaning. These things are simply outside its framework.

Capitalism cares about exchange valueabout what can be bought and sold, priced and traded. It’s magnificent at coordinating production and distribution around exchange value. But it’s completely indifferent to everything else.

A capitalist system will happily destroy a forest if the profit from logging exceeds the loss. It will extract value from human suffering, from addiction, from loneliness. It will optimize for engagement metrics that corrode human attention. It will treat human relationships as data to be monetized. Not because capitalists are evil, but because the system has no category for “things that matter but aren’t profitable.”

Capitalism doesn’t have a conscience. It isn’t cruel. It’s amoral. It operates according to its own logic, which is: extract maximum value, minimize cost, optimize efficiency. Apply that logic consistently enough and you get outcomes that would horrify most humans. But capitalism doesn’t feel horror. It just feels profit.

This isn’t a criticism of capitalism. It’s a description of what it is. You don’t criticize a hammer for not being a saw. But you also don’t use a hammer to perform surgery and then act shocked when the patient bleeds.

The Moral Colonization

What’s troubling is not that capitalism exists. It’s that capitalism has colonized the spaces where moral questions should be asked.

We’ve let capitalism define what counts as valuable. If something can’t be priced, it barely exists in our framework. Art that doesn’t sell is dismissed as self-indulgent. Care work is undervalued because it’s hard to monetize. Community is treated as quaint nostalgia. A forest is worth its timber value, nothing more.

We’ve let capitalism define what counts as success. Your life is measured in income and consumption. Your worth is correlated with your net worth. You’re successful if you’ve maximized your economic value. Everything else is secondary.

We’ve let capitalism define what counts as rational. To act “rationally” means to maximize your economic interest. To care for something that doesn’t generate profit is irrational. To sacrifice income for principle is irrational. To refuse a lucrative opportunity because it violates your values is irrational.

And worst of all, we’ve let capitalism define what counts as moral. We tell stories about how the market rewards virtue and punishes vice. Hard work gets compensated; laziness doesn’t. We deserve what we’ve earned. The wealthy have earned their wealth through merit and effort. If you’re poor, it’s because you haven’t worked hard enough or made good choices.

These stories are comforting. They suggest the system is just. They let the winners feel they deserve their winnings. They let the losers blame themselves for losing.

But they’re false. Capitalism doesn’t reward virtue. It rewards whatever generates profit. Sometimes that’s skill and effort. Sometimes it’s luck. Sometimes it’s ruthlessness. Sometimes it’s having the right parents. The system is mechanically indifferent to morality.

The Principle Stack That Capitalism Demands

When you accept capitalism not just as an economic tool but as a moral framework - when you let it colonize all the spaces where you make meaning - your principle stack becomes constrained in a particular way.

Profit naturally rises to the top. Not because you’ve consciously chosen it, but because every institutional signal, every incentive structure, every measure of success pushes you in that direction. The system trains you to prioritize what serves the system.

And once profit is at the top, everything else reorganizes itself beneath it. Ethics become a constraint to minimize rather than a principle to maximize. Care for others becomes charity (something you do with your excess) rather than a foundational value. Community becomes a market to exploit rather than a place to belong. Your own time and attention become resources to be monetized.

You’re not evil for operating this way. You’re just accepting the default stack that capitalism provides. The stack that makes you maximally useful to the system.

But here’s what’s crucial: it’s a choice to accept that stack.

This is where the real argument gets sharp. Capitalism will always try to order your principles this way. It’s designed to. The incentives are relentless. The pressure is constant. The stories are seductive. But capitalism cannot force you to accept its moral authority. You can recognize it as a tool and refuse to let it define what matters.

The Human Capacity for Resistance

This is where reason - that thing that supposedly differentiates us from animals - actually comes into play.

You can look at capitalism and say: yes, this is efficient at allocating resources. Yes, I need to participate in it to survive. Yes, the incentives are real and the costs of defection are high.

And then you can say: but I’m not going to let it define what I value. I’m going to maintain principles that capitalism says are inefficient. I’m going to care for people who can’t pay me. I’m going to make art that won’t sell. I’m going to build community instead of markets. I’m going to treat some things as sacred - not to be priced or traded or optimized.

This isn’t irrational. It’s the highest use of reason. Reason isn’t just about maximizing utility. It’s about ordering your principles consciously, in full awareness of what you’re choosing and what it costs.

An animal operates according to instinct and immediate incentive. A human can override immediate incentive in service of principle. A human can look at the direction the system is pushing and choose differently.

That capacity - to choose your principle stack despite systemic pressure - is what makes you human.

The Cost of Consciousness

But let’s be honest about what this choice requires.

If you maintain principles that capitalism says are inefficient, you will pay a price. You’ll make less money. You’ll have fewer options. You’ll move slower. You’ll accumulate less. You’ll be less successful by capitalism’s metrics.

Some people can afford this price. They have family money, or talent in a lucrative field, or they got lucky early. For them, the choice to maintain their principle stack is more manageable.

Others face the choice with teeth. The price is real: food security, healthcare, the ability to provide for dependents. When that’s the cost, the choice becomes genuinely difficult.

This is where it gets important to be honest about capitalism’s coercive power. The system doesn’t just incentivize particular principle stacks. For many people, it coerces them. When your alternative to accepting capitalism’s moral authority is destitution, the “choice” is real but not free.

But even within that constraint, there’s still a spectrum of choice. You can organize your resistance locally - within your household, your community, your small corner of the system. You can refuse some compromises even if you can’t refuse all of them. You can maintain some principles at the top of your stack even if capitalism forces others lower.

The point isn’t that you can escape capitalism and be purely moral. You can’t. The point is that you can refuse to let it be the only organizing principle. You can accept it as a tool while protecting the spaces where other values dominate.

What It Looks Like in Practice

This isn’t abstract. It’s about real choices.

It looks like a parent working a stable job for security, but insisting that some evenings are for family and not for income-generation. It’s inefficient. It costs money. But they’re choosing community over profit.

It looks like an engineer refusing a lucrative offer because the work would require compromising ethics. It’s inefficient. It costs a lot. But they’re choosing integrity.

It looks like an artist making work that won’t sell because it matters to them. It’s inefficient. It almost guarantees economic precarity. But they’re choosing meaning.

It looks like a company that could cut labor costs and boost margins, but doesn’t, because they’ve decided that care for employees is a foundational value. It’s inefficient. It hurts quarterly returns. But they’re choosing to order their principles differently.

It looks like communities that organize outside the market - sharing, mutual aid, gift economies - because some things shouldn’t be priced. It’s inefficient by capitalism’s metrics. But it recognizes that efficiency isn’t the highest good.

None of these are pure. None of them escape capitalism entirely. But they all represent people and communities saying: we recognize this system for what it is, and we’re going to refuse to let it be the only source of moral authority.

The Political Act

Here’s what’s radical about this: maintaining a principle stack that defies capitalism’s pull is a political act.

Not in the sense of electoral politics. In the sense of asserting that humans are not merely economic animals, and that we will not be ordered solely by economic logic.

It’s saying: we have the capacity to reason about what matters. We have the capacity to choose principles despite incentive structures that push us otherwise. We will use that capacity. We will order our lives according to values that cannot be priced.

This is threatening to capitalism not because capitalism is evil, but because it works. Once some people start maintaining alternative principle stacks, once communities start organizing outside profit-maximization, once humans start using their reason to defect from capitalism’s preferred ordering - the system loses its totalizing power.

This is why capitalism constantly works to colonize the last remaining spaces of resistance. Why it tries to monetize friendship, turn hobbies into side hustles, price experiences, commodify meaning. Every space where humans organize around principles other than profit is a threat to capitalism’s hegemony.

Not because capitalism is consciously defending itself. Just because removing obstacles to profit-maximization is what capitalism does.

The Reconciliation

None of this is an argument that capitalism should be destroyed, or that we should pretend it doesn’t work, or that we can escape it.

Capitalism is good at what it does. If you need to allocate scarce resources efficiently, capitalism is a tool you probably want. And you probably need it at least partially - most of us do.

The argument is simpler: stop mistaking the tool for morality.

Recognize capitalism for what it is: a mechanism for coordinating economic activity. It’s efficient. It’s useful. It’s probably necessary for modern life. But it’s amoral. It has no conscience. It doesn’t know what matters.

Which means you have to know what matters. You have to decide what matters. You have to order your principle stack in a way that capitalism won’t naturally produce.

Some economic inefficiency is worth the trade. Some profit should be left on the table in service of other values. Some things should never be priced. Some humans should be cared for not because they generate value, but because they’re human.

These choices require using your reason to override capitalism’s preferred ordering. They require maintaining principles that the system says are inefficient. They require conscious resistance.

But they’re choices you can make. You’re not trapped. You’re not forced. You’re not slaves to the system unless you accept its moral authority.

You can use capitalism as a tool while refusing to be ordered by it. You can participate in the system while maintaining principles that transcend it. You can be human - in the full sense of that word, with reason and conscience and the capacity to choose - while also living in a capitalist economy.

It’s harder than accepting the default stack. It costs something. But it’s possible.

And maybe the fact that it’s possible - that humans retain the capacity to reason about and choose their principles despite systemic pressure - is the most important thing to remember.

From balmy morning to winter wonderland

The day opened quietly. At 7:00 AM, the temperature sat at a comfortable 75°F, a southwest breeze carrying the particular warmth that makes you believe, wrongly, that winter is done. People were out in t-shirts. The air had that loose, unhurried quality of a morning that doesn’t know what’s coming.

By 9:00 AM, the wind had shifted sharply to the north. What followed wasn’t a gradual cooling - it was a door swinging shut. Within a few hours, the mercury had dropped from the 70s into the 30s. By early afternoon, the rain had turned to snow, and the Virginia landscape wore a brief, incongruous coat of white.

The cold front: a natural phenomenon

The mechanism behind this was a classic cold front - the leading edge of a denser, colder air mass. In this case, a Canadian high-pressure system had funneled south down the East Coast with unusual force. That air mass behaved like a wedge, driving under the warmer surface air and forcing it upward sharply. The rapid lift, the temperature gradient, the wind reversal - all of it followed from that single collision.

A “Blue Norther”

There’s a name for this kind of event in the Great Plains: a Blue Norther - a rapidly advancing arctic cold front that can drop temperatures by 20°F to 40°F in minutes rather than hours. The name is thought to come from the appearance of the approaching front: a dark, blue-black wall of cloud at the horizon, with a deep, cold blue sky trailing behind it.

The Mid-Atlantic doesn’t see Blue Northers often. Our geography softens most of what comes down from Canada. But last Thursday’s front was close kin - the physics identical, the drama nearly so. It’s worth imagining that wall of cloud pushing south from the Plains, crossing the Appalachians, arriving here with its name still on it.

Visualizing the front

The most effective way to see the impact of this cold front is to look at a meteogram, which is a graph that plots weather variables over time. Here’s one I drew using data from Richmond International Airport:

The temperature drop around 9:00 AM is the sharpest feature. Notice too the simultaneous wind direction shift - southwest to north - which marks the exact moment the front arrived.

False Spring

Richmond sits in an odd meteorological position: close enough to the coast to stay warm, open enough to the north to get blindsided. We’re known for false springs - teasing warm stretches in February and March that dissolve overnight. But a 40-degree drop in six hours is extreme even by local standards.

The cold front that moved through last Thursday was a reminder that the atmosphere doesn’t negotiate. It arrives, it changes everything, and then it’s gone - leaving snow on the ground and everyone reaching back into the closet for a coat they thought they were done with.

But there’s another kind of stack worth examining. Not the one beneath your principles, but the one among them. The ordering.

Because you don’t hold just one principle. You hold many. Freedom of expression and responsibility for consequences. Privacy and security. Integrity and survival. Loyalty and honesty. Growth and sustainability. Profit and ethics.

The problem is that these principles don’t exist in isolation. They collide. They contradict. And when they do, something interesting happens: your actual principle stack¹ - the one that really governs your behavior - becomes visible.

The Revealed Stack

You can claim whatever principles you like. But your actual stack reveals itself in the moment of conflict.

Consider Facebook and privacy. In the early years, when the company was fighting for survival, growth was necessarily near the top of the stack. That made sense. A startup that doesn’t grow doesn’t exist. But as Facebook matured - became dominant, profitable, powerful - the context changed completely. The stack should have reorganized. A company with Facebook’s resources and position could have made privacy a top principle. The fact that it didn’t reveals what was actually being chosen.

For years - decades - the company articulated a principle: user privacy matters. It appeared in mission statements. It showed up in public commitments. It was woven into product philosophy.

But when privacy conflicted with engagement metrics (which drove advertising revenue), the stack became clear. Privacy was not at the top. It was somewhere much lower, buried beneath growth, engagement, and profit.

This wasn’t a secret. The evidence was everywhere. Terms of service changed. Data collection expanded. Opt-out became harder. Users complained. Regulators noticed. And yet the behavior continued, because the actual principle stack - the one revealed through sustained choice - hadn’t changed even as the conditions that might have justified it did.

The interesting part is that Facebook probably believed in privacy as a principle. It’s not that the executives were cartoon villains who didn’t care. It’s that when push came to shove, other principles won. And they kept winning. And at some point, what you choose repeatedly is your stack, regardless of what you claim.

But this matters even more in the context of time and circumstance. The stack that made sense at one stage of the company’s life - survival-focused, growth-driven - became a choice at a later stage, when different stacks were actually possible.

The Stack Through Time

Here’s what complicates the picture: your principle stack isn’t fixed. It shifts.

A young engineer entering the workforce might have integrity and craftsmanship high in their stack. These are principles they can afford. They have few dependents, minimal financial obligations, options if they walk away from a bad situation.

Then they get married. Buy a house. Have a child. Health insurance becomes critical. Suddenly survival is higher in the stack than it was before. Not because they’ve become corrupt or abandoned their values - but because the weight of actual responsibility has changed. They have people depending on them.

This isn’t moral failure. It’s adaptation to circumstance.

Similarly, a startup founder’s principle stack when they’re bootstrapped and fighting for survival looks very different from their stack once the company is stable and profitable. When you might not make payroll next month, growth and survival naturally sit higher than long-term sustainability or work-life balance. When you have runway, you can afford different principles.

And as you live longer, you learn things about yourself. What you thought you valued, you discover you don’t - or vice versa. You find that autonomy matters more than you expected. Or that community does. Or that leaving a legacy matters in ways you didn’t anticipate. Your self-knowledge increases, and your stack reorganizes accordingly.

This is all entirely normal. Expected, even. The stack you have at 25 managing your own code is not the same as the stack you have at 45 managing a team. Neither is right or wrong - they’re adapted to different contexts.

But here’s what makes it morally significant: even as your circumstances change, you’re still making choices about how to reorganize your stack. You can choose to maintain integrity even when survival pressure increases. You can choose to keep craftsmanship high even when speed is more profitable. You can choose to reorganize your stack as your context changes, rather than defaulting to whatever pressure pushes you.

The point isn’t that your stack should stay the same. It’s that you should be aware when it’s changing, and why.

Stacks in Transition

This is where the Facebook example gets more complicated and more revealing.

In the early days - the first few years - Facebook’s stack made sense. Growth was survival. User privacy was less of a technical or ethical priority than user engagement. The context demanded it.

But Facebook didn’t stay small. It became the largest social network in the world. It became profitable, powerful, essential infrastructure. The context changed completely. A company in that position - with those resources, that dominance, that responsibility - could have reorganized its stack. They could have elevated privacy, ethics, long-term thinking.

The fact that it didn’t reveals a choice. Not a forced circumstance, but an actual choice to keep the stack organized around growth and profit even after the conditions that made survival the priority had long passed.

This is the moment where the revealed stack becomes damning. It’s not the scrappy startup. It’s the mature company making the same choice it made when it had to, even though it doesn’t have to anymore.

For individuals, the equivalent is keeping the stack you needed to survive in hard times, long after you no longer need to. The person who clawed their way out of poverty and built security, but never reorganizes their principles once they have actual security. They keep operating as if survival is at the top, even though it isn’t anymore. That’s not adaptation - that’s inertia wearing the mask of principle.

The Impossibility of Prediction

Here’s what I don’t think is true: that you can know your principle stack in advance.

This isn’t just because most people don’t sit down and consciously order their values. It’s also because your stack will change as your circumstances change. The stack that fits your life at 30 won’t fit your life at 40. The stack that works when you’re secure won’t look the same as the stack you needed to survive precarity.

You can make educated guesses about what matters to you. You have values. You have convictions. But the actual ordering - which principle will win when two collide - often remains unknown until the moment comes. And even if you predict accurately today, that prediction might be obsolete next year.

It’s easy to say “I value integrity and profit equally” when profit isn’t threatened. It’s a different question when your income depends on looking the other way, or when you have mouths to feed and the integrity costs you something real.

It’s easy to say “I believe in free expression and responsibility” when you’re not the one managing the platform where harmful speech is happening.

It’s easy to say “I prioritize sustainability” when the sustainable choice doesn’t cost you anything. It’s harder when it means less income, more complexity, fewer options, delayed growth.

The stack doesn’t reveal itself through introspection. It reveals itself through behavior, under pressure, over time. And it reveals itself anew in each new context you enter.

This is why so many principles-related failures feel like surprises to the people committing them. A manager genuinely believes they value employee wellbeing. Then the quarter goes badly and they lay people off. They weren’t lying before - they were just encountering a situation where another principle (survival of the business, performance metrics, shareholder returns) was higher in the stack than they’d realized. And in that moment, facing that particular pressure, their stack reorganized itself.

It’s not that their earlier claim was false. It’s that their stack was always contextual - shaped by what they’d faced, what they needed to survive, what they’d been forced to choose. Put them in a new context with new pressures, and the stack shifts.

The Capitalism Problem

There’s a structural issue worth naming here: capitalism creates a powerful gravitational pull toward certain principles at the top of the stack.

In a system where your survival - or success, or comfort, or growth - depends on financial metrics, profit naturally migrates upward in your principle hierarchy. It doesn’t need to be intentional. It’s just physics.

You can have beautiful principles about quality, craftsmanship, taking care of your team. But if the financial system rewards the opposite - if speed to market beats quality, if headcount reduction beats employee wellbeing, if growth beats sustainability - then every day you’re making micro-choices that slowly recalibrate your stack.

Not because you’re corrupt or cynical. Just because the incentive structure works. You compromise a little here to hit a deadline. You defer investment there to improve margins. You rationalize a decision about labor or materials or safety because “everyone does it.” And bit by bit, the stack reorganizes itself around what the system actually rewards.

This isn’t unique to capitalism. Any system - political, social, organizational - creates incentives that push certain principles higher in the stack. But capitalism is particularly effective at it because it operates on a clear quantifiable metric (profit) that’s easy to track and compare.

When profit is the scoreboard, it becomes hard to argue that it shouldn’t sit near the top of your stack.

The Choice That Remains

But here’s where personal accountability comes in. And why this matters.

Even if the system is pushing in a certain direction, you still have a choice about your stack. Not an easy choice, usually. Not a choice without cost. But a choice nonetheless.

You can choose to take less profit in exchange for higher principles. You can choose to accept less growth to prioritize sustainability. You can choose to walk away from an opportunity because it violates something deeper.

People do this. Some do it consistently. They don’t get rich. They don’t maximize. They don’t win by the scoreboard that everyone else is watching. But their principle stack is coherent, and they know what they’ve chosen.

More commonly, people don’t make this choice. They work within the system. They optimize for what the system rewards. They tell themselves stories about how their hands are tied, how this is just how the world works, how you can’t change the system from outside so you might as well succeed within it.

Those are not illegitimate stories. The constraints are real. The pressure is real. The cost of defection is real.

But it’s still a choice.

And I think the clarity that comes from acknowledging that choice - understanding your actual stack, not your claimed stack, and recognizing that you’re choosing it every day - might be more important than getting the stack “right”.

Because you probably won’t get it right. You’ll probably find that some of your principles aren’t where you thought they were. You’ll discover that you value comfort more than you admitted, or that you’re willing to sacrifice more for community than you expected. You’ll encounter situations you didn’t anticipate and make choices you didn’t know you were capable of.

That’s not failure. That’s information. That’s how you actually come to know yourself.

What to Do With It

If your principle stack is revealed through choices, and if you can’t know it in advance, what’s the point of thinking about it?

The point is this: you can become aware of the revelation as it happens. You can feel when principles collide and notice which one wins. You can ask yourself: did I choose that? Or did I just default to whatever the system was pulling me toward?

That awareness doesn’t guarantee you’ll change your behavior. But it opens the possibility of doing so. It lets you see the cost of your choices rather than pretending they weren’t choices at all.

You can look at your actions and say: this is my stack. These are my priorities, whether I intended them to be or not. This is what I actually value, as demonstrated by what I actually do.

And then you can ask: is this the stack I want? And if not - if you discover that profit is higher than integrity, or convenience is higher than principle, or self-preservation is higher than ethics - then you at least know what would need to change.

It might be hard. It might be costly. It might require sacrificing something you’re not willing to sacrifice. But at least you’d know the choice you were making.

That’s more honest than most people manage. It’s also the only place where real change becomes possible.

What we don’t usually do is ask where they come from, or why they work.

That question turns out to be more interesting than it looks, and thinking it through carefully gives you something useful: a cleaner framework for developing new principles when you encounter situations where the existing ones don’t apply.

The answer involves three distinct concepts - mental models, axioms, and maxims - that most people use interchangeably but that actually sit in a specific relationship to each other. Get that relationship right, and the whole thing becomes a tool rather than just vocabulary.

The Three Concepts

Mental models are descriptive frameworks for how something works. They’re not rules; they’re lenses. “Compound interest” is a mental model - not a rule for what to do, but a way of understanding how small things accumulate exponentially over time. “Cascading failures” is a mental model for how distributed systems break. “Technical debt” is a mental model for the relationship between speed now and cost later.

Mental models explain mechanics. They answer “how does this actually work?”

Axioms are foundational truths extracted from those models. Once you deeply understand a mental model, certain things become unavoidably true within it - truths that you accept as starting points for reasoning rather than conclusions you’re still trying to prove. “Everything fails eventually” is an axiom that flows from understanding how distributed systems behave at scale. “Deferred problems accumulate cost over time” is an axiom from the technical debt model.

Axioms are descriptive, not prescriptive. They state what is, not what you should do.

Maxims are the action layer. They’re rules of conduct derived from accepting certain axioms as true. “Design for failure” is a maxim that makes sense because you’ve accepted that everything fails eventually. “Fix it now or pay more later” makes sense because you’ve accepted that deferred problems compound. “Always have a rollback plan” follows from knowing that deployments can go wrong and that the cost of being unable to revert is high.

Maxims are prescriptive. They tell you what to do.

The Stack

The relationship between them moves in one direction:

Mental model → Axiom → Maxim

The mental model gives you the explanatory framework - the mechanics of how something actually behaves. The axiom is the fundamental truth you extract from that understanding. The maxim is the actionable principle you derive from accepting that truth.

This hierarchy matters because it explains something that engineers often notice but can’t quite articulate: some maxims feel wise and some feel arbitrary, even when both claim equal authority. The difference is usually that the wise ones have a full stack underneath them, while the arbitrary ones are floating free.

“Never deploy on a Friday” might be a reasonable maxim - or it might be cargo cult. It depends on whether it’s connected to an axiom (something like “systems problems compound over weekends when you have reduced staffing”) that flows from a mental model (how incident response works under reduced availability). If the connection is there, the maxim is wise. If it’s just repeated because someone once had a bad Friday, it’s superstition wearing the clothes of principle.

Why This Matters for Systems Work

A lot of engineering decision-making involves situations where the existing maxims don’t quite fit. You’re in a context that’s novel enough, or constrained enough, that the rules of thumb don’t clearly apply. At that point, you have two options: pick the closest-sounding rule and hope, or reason from the underlying model.

The second option requires having the model.

Consider a team debating whether to add redundancy to a critical service. “Design for failure” says yes, obviously. But the real question is how much redundancy, at what cost, and at what complexity tradeoff. The maxim can’t tell you that. The mental model - understanding how your actual failure modes behave, what the blast radius of each looks like, how your team responds to incidents - lets you reason toward an answer that’s calibrated to your specific situation rather than borrowed from a generic principle.

Or consider the question of when to pay down technical debt. “Fix it now” and “ship it” are both legitimate maxims in different contexts. Choosing between them requires understanding the actual mechanics of how debt accumulates in your codebase and your team, which then lets you make axiom-level statements about your specific situation (“in this service, with this team size, debt in the authentication layer has disproportionate downstream cost”) that inform a local maxim that actually fits.

The mental models are what make you adaptable. The axioms are what give your reasoning integrity. The maxims are what make you fast.

Building Your Own

Most practitioners collect maxims over time - rules that have worked, principles they’ve picked up from experience or reading. That’s useful. But the richer practice is to run them backward occasionally.

When you have a maxim that seems to hold up: what axiom is it based on? What mental model produces that axiom? If you can complete the stack, you understand why the rule works, which tells you a lot about when it applies and when it doesn’t.

When you encounter a situation the existing maxims don’t cover: what mental model best describes the dynamics at play? What truths does that model surface that you’d accept as foundational? What behavior follows from accepting those truths?

That’s how you derive new maxims that are connected to understanding rather than just convention.

The goal isn’t to have more principles. It’s to have principles that are actually rooted in how things work - so that when the situation is new, you’re reasoning rather than guessing.

Understanding → truth → action. In that order.

I am working on a few posts about topics I think are currently interesting in software development. I shared one of them with a friend to get feedback on what I had written. His response made me realize that the post contained more background material than the discussion I was trying to have. I immediately thought of Thomason: “I had to tell you that to tell you this…”

The basic problem here is that a blog post is open to everyone on the internet to read, but everyone on the internet is far too broad an audience for any post I write. (Or indeed any post anyone writes.)

What’s more, for any given post I write, there is an implicit audience. You as reader have no way of knowing who I have in mind. Maybe I am thinking of “the whole internet,” but that certainly isn’t the case for most posts. So what if I just made my intended audience explicit?

My current best solution for handling this is an assumed audience heading on the top of a post. Think of it as a sign-post for people to understand who I was thinking of while writing. A few examples:

• Assumed Audience: parents of teenagers
• Assumed Audience: people curious about Earth history
• Assumed Audience: people who enjoy nature and travel
• Assumed Audience: other experienced software engineers

Each of those are people I might actually address on this blog  -  and there are plenty of others, of course. What’s potentially useful about this kind of thing is that good-faith readers know how to approach the content.

Thomason used his signature line to earn his digressions. Perhaps a small two-line header at the top of a post can do the same work for me.

As I grew, my affinity for the bridge led others to associate me with its namesake. I leaned into it. Washington was certainly an impressive figure, but my connection to him having begun with a bridge built long after his death means I’ve never taken the association too seriously. In that spirit, I’ve collected a few stories about the man that I find particularly amusing:

In Citizens: A Chronicle of the French Revolution, Simon Schama mentions the publication of Portraits des Grands Hommes Illustres de la France, an anthology of patriotic heroes in the late 1780s. One prominent plate from 1786 celebrates Louis XVI as the benefactor of American independence, showing him alongside Benjamin Franklin, George Washington, and the personification of America, who holds aloft the hat of liberty while trampling a British imperial beast.

Curiously, the plate misspells Washington’s name as “Waginston”. That has always amused me, to the point of chuckling out loud.

There’s a small bathroom off my home office that rarely gets used by anyone but me. As a result, “Dad’s bathroom” is sparsely decorated and has a utilitarian feel.

As a Christmas present this past year, my kids used AI to generate this image. They had it printed and presented it to me with the suggestion that it would go perfectly above the toilet in that bathroom. And it does.

Speaking of pictures of George Washington near toilets, Abraham Lincoln was fond of telling an apocryphal story about Ethan Allen’s visit to England in 1783. Daniel Day-Lewis performs its telling in the movie Lincoln:

It was right after the Revolution, right after peace had been concluded. And Ethan Allen went to London to help our new country conduct its business with the king. The English sneered at how rough we are and rude and simple-minded and on like that, everywhere he went. ’Til one day he was invited to the townhouse of a great English lord. Dinner was served, beverages imbibed, time passed as happens and Mr. Allen found he needed the privy. He was grateful to be directed thence. Relieved, you might say. Mr. Allen discovered on entering the water closet that the only decoration therein was a portrait of George Washington. Ethan Allen done what he came to do and returned to the drawing room. His host and the others were disappointed when he didn’t mention Washington’s portrait. And finally his lordship couldn’t resist and asked Mr. Allen had he noticed it - the picture of Washington. He had. Well what did he think of its placement? Did it seem appropriately located to Mr. Allen? And Mr. Allen said it did. The host was astounded. “Appropriate? George Washington’s likeness in a water closet?” “Yes,” said Mr. Allen, “where it will do good service. The whole world knows nothing will make an Englishman shit quicker than the sight of George Washington.”

Temperature scales force us to choose: do we design for abstract universality, or for embodied human experience? The answer reveals how seemingly objective technical standards embed human values.

To explain how, let’s examine what goes into creating a temperature scale.

Let’s invent a temperature scale

Imagine we’re sitting at a wooden table, trying to build our own temperature scale from scratch.

First, we need to agree on something simple:

When two things sit next to each other long enough, they eventually feel the same temperature.

If a cup of coffee cools down in the room, it eventually matches the room. This equilibrium tells us temperature is something real, not a feeling - it is a property that equalizes. That’s useful - it means we can measure it.

Now we need a tool - something that changes in a steady, predictable way when things get hotter or colder. Our own experience tells us that liquids expand and gases increase pressure with changing temperature.

Let’s say we choose a liquid in a glass tube. When it gets hotter the liquid rises in the tube; it falls as it cools. We can use that as a measuring stick.

At this point, we can compare temperatures, but we haven’t attached numbers to it yet. We need to choose meaningful anchors. Where do we put zero? It’s up to us!

Zero is just a choice. Do we want zero to mean the freezing point of water? A very cold day? A comfortable indoor temperature? Every decision shapes how our scale feels to use.

Let’s decide to set 0° to mean a really cold winter day where exposed skin hurts. And let’s make 100° describe a brutally hot day where you don’t want to move. Our entire human weather experience fits roughly between 0 and 100. That makes the numbers intuitive.¹

Alternatively, we could choose to make 0° equal to the freezing point of water at sea level, and 100° the boiling point of water. That would make our scale scientifically tidy.²

Different goals mean different anchors.

Next question: Do we want big jumps between numbers, or small ones? If each degree represents a tiny change, we get precision; if it represents a larger jump, the numbers are simpler.

We must decide: is this scale for everyday conversation? For cooking? Scientific measurement? Weather reports? Our purpose shapes our design.

And here’s where the Fahrenheit choice becomes clear: its degrees are smaller - each one represents about 5/9 of a Celsius degree. That finer granularity means the range of human comfort (roughly 60-80°F) spans twenty distinct integer values instead of Celsius’s dozen (15-27°C). You get precision without needing decimal points. It’s scaled to what humans can perceive.

We’ve set the physical property (liquid height in a tube), the reference points (our 0 and 100), and the spacing between the numbers. We’re done!

We now have a temperature scale.

What the choices reveal

Our temperature scale hasn’t changed the world. The air is the same warmth, the coffee has the same heat. We’ve just created a new way to describe and label it.

Temperature scales aren’t discovered; they are designed. They are constrained by physics, but shaped by human priorities.

I’ll happily admit that Celsius’s scale is more elegant than Fahrenheit’s. It’s clean and scientific. But his anchors are about water, not people.

Creating a temperature scale is a tiny act of civilizational philosophy. The metric system - and the Celsius temperature scale - centers universality and abstraction. Fahrenheit centers embodied human experience. One is a scale of nature, the other is a scale of habitation.

This is a tension I feel as an engineer. My instinct prefers metric rationality and scientific clarity, but I feel Fahrenheit’s humanism.

The question “what are we measuring for?” shows up everywhere I work. When I design an API, am I optimizing for internal consistency or for the mental model developers have? When I structure a database schema, am I chasing normalization or the queries people will actually run? When I write an error message, am I reporting what the system knows or what someone needs to fix the problem?

These aren’t always the same answer.

Fahrenheit reminds me that the best technical standard isn’t always the most universal one. Sometimes the right choice is scaled to human perception, anchored in lived experience, built for the people who have to use it every day.

I think that’s worth keeping in mind.

These thoughts held me back from publishing my writing for years. I believed that writing privately was only a way for me think and learn - to connect thoughts, concepts, and perceptions in my mind. While this was true, I began to recognize that by not sharing my writing, I was missing out on the opportunity to engage with others about my creations.

Something changed last year. I now realize my experiences and insights are worth sharing. I want to counter increasing social isolation by reaching out and connecting with other people. As an act of rebellion against mass-marketed content and AI-generated slop, I aspire to claim an area of the web as my own.

This website represents the first wager in my Year of Small Bets¹. I am delighted you are here. My objective is to engage in public experimentation by sharing my thoughts and creations. Rather than setting lofty expectations, my modest goal is to create a site I’d enjoy visiting and sharing with others.

If you’re interested in following along, you can subscribe to my feed, subscribe to my periodic newsletter, or bookmark this page.

I look forward to staying in touch.