Choosing zero

I am a strong proponent of the metric system. Elegant and universal, the decimal simplicity makes everything easier. So why do I find myself defending Fahrenheit? This inconsistency bothers me, or at least it used to. Now I think it reveals something important about what happens when we design technical systems.

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.