跪拜 Guibai
← Back to the summary

The Map Is Not the Terrain: Why Every Name in Software Is a Lie

The Juejin column may not be updated in time. Everyone is welcome to visit Dao De Jing: The Path of Programming

The Dao that can be told is not the eternal Dao; the name that can be named is not the eternal name.
The nameless is the beginning of heaven and earth; the named is the mother of ten thousand things.
Therefore, constantly without desire, one observes its mysteries; constantly with desire, one observes its manifestations.
These two emerge together but differ in name; the unity is called the mystery. Mystery upon mystery, the gateway to all wonders.

The first chapter of the Dao De Jing is immediately counter-intuitive.

In our daily technical and product work, what do we like most? Definitions.

Requirements need to be defined, fields need to be defined, interfaces need to be defined, processes need to be defined, metrics need to be defined. Ideally, everything has a name, a boundary, an owner, and a schedule.

This is certainly important. Without definitions, teams cannot collaborate; without naming, systems cannot express themselves; without documentation, complex work quickly becomes a tangled mess.

But Laozi's first chapter reminds us: What can be clearly stated is often only a part of the thing; what can be named is often no longer the whole of the thing.

This insight remains remarkably sharp when applied to today's world of technology and products.

1. What are Dao and Name really talking about?

"The Dao that can be told is not the eternal Dao."

The first "Dao" here can be understood as the underlying laws, the mode of operation, the true logic behind things. The second "Dao" means to speak, to express, to describe.

So this sentence does not mean "the Dao cannot be spoken of," but rather: Any law that can be completely spoken and fixed in writing is not the eternal, unchanging law itself.

For example, you write a "System Architecture Design Document." It certainly has value. But it is not the system itself. The real system exists in the code, traffic, dependencies, historical baggage, team habits, online incidents, and user behavior.

The document is just the map; the system is the terrain.

"The name that can be named is not the eternal name."

This sentence is also not against naming. On the contrary, naming is extremely important. Every programmer knows that good naming can save lives, and bad naming can make people doubt their existence.

But Laozi reminds us: A name is just a label artificially carved out; it is not equal to the thing itself.

For instance, a field called status seems very simple. But when you actually maintain it, you might find it hides a dozen different states:

The name is status, but the real world is never as clean as a single field name.

"The nameless is the beginning of heaven and earth; the named is the mother of ten thousand things."

Before there were names, the world was chaotic, whole, and undivided. After names came into being, we could classify, identify, communicate, and manage.

This is very similar to product development.

Users initially have only a vague feeling: "This thing is not easy to use," "This is troublesome," "I can't find what I want." The product manager must break this vague feeling down into requirements, processes, pages, interactions, and metrics.

Naming makes the world operable, but it can also make us mistakenly believe we already understand the world.

2. A requirements document is not the requirement, and a PRD is not the user

People who build products encounter this problem most easily.

A user says: "I want an export function."

So the requirements document writes:

Add a data export function, supporting Excel download.

Seems very clear, right?

But this is just the "Name." It has been named an "export function." The true "Dao" might be:

If you don't continue to ask questions, you might build a very standard but not very useful export button.

In the end, the user is still dissatisfied, because what they really wanted was not "export," but "deliverable," "analyzable," "provable," or "collaborative."

This is the meaning of the first chapter: The name is the entrance, not the truth.

If a product manager only stops at the requirement name, they become a "feature porter." Whatever the user says they want, they schedule it; whatever the boss says to do, they break it down; whatever the competitor has, they copy it.

But truly good product judgment often happens before naming.

You have to ask:

Very often, what the user says as "I want a button" translates into human speech as: "I currently have no sense of security."

This is where product work becomes interesting.

3. A variable name is not the business logic, and an interface name is not the design

Programmers also cannot escape the trap of the "Name."

For example, you see a variable:

const isValid = checkUser(input)

It looks very clear: the user is valid.

But what does "valid" mean?

Is the format valid? The permissions valid? The account status valid? The risk control valid? The membership valid? Valid in the current business context?

If you don't look at the context and only trust the variable name, it's easy to step on a landmine. Because the "Name" in code is often just a simplified expression left over from a specific historical moment.

Another example is an interface called:

GET /api/order/detail

It sounds like just "order details." But it might be shouldering too many responsibilities:

The interface name is detail, but the real behavior might have already become "the backend master control center for the order detail page."

Therefore, a mature programmer doesn't just look at the name. They look at the call chain, data flow, exception branches, commit history, and online performance.

Because they know: Naming helps us understand the system, but the system doesn't become simpler just because the naming sounds nice.

4. "Without desire, observe its mysteries": Don't rush to conclusions

"Constantly without desire, one observes its mysteries" is a sentence particularly suited for troubleshooting problems.

When an online incident occurs, many people's first reaction is to find a familiar cause:

These guesses are not necessarily wrong, but if you settle on an answer too early, you will be led astray by your own experience.

"Without desire" does not mean having no goal; it means first letting go of attachments. Observe the phenomenon first, and don't rush to label it.

For example, with an interface timeout, you can first look at:

This is "observing its mysteries."

It is not mysticism, but systematic observation.

By temporarily not rushing to prove yourself right, you are more likely to see the true state of things.

5. "With desire, observe its manifestations": With a goal, see the boundaries clearly

But observation alone is not enough.

"Constantly with desire, one observes its manifestations" means that when you look with a goal, you can see the boundaries, results, paths, and limitations.

When troubleshooting, after observation comes convergence:

The same applies to product development.

You need to "without desire" observe users, not rushing to force user behavior into your own presuppositions; but you also need to "with desire" make trade-offs, clarifying exactly which problem the current version is solving.

Only "without desire" easily leads to boundless research. Only "with desire" easily leads to finding evidence to support your KPIs.

Good products and good engineering both require switching back and forth between these two perspectives.

First open up, then converge. First see the complexity, then simplify.

6. A product example: Does the user really need "tags"?

Suppose you are building a note-taking product.

User feedback: "Can you add a tag feature? I want to categorize my notes."

This sounds very reasonable. Many products have tags, and it doesn't seem too hard to build.

But if you only hear the name "tags," it's easy to jump straight into the solution:

After the feature launches, the user might be happy at first, but after a while, they stop using it.

Why?

Because their real problem might not be a "lack of tags," but:

If you see this layer, your solution might be different.

You might prioritize optimizing search, or build automatic associations, or recommend related content while the user is writing, or reduce the cost of manual organization.

Tags are the "Name"; information retrieval might be the "Dao."

7. A technical example: Refactoring does not equal improvement

There are many words in technical teams that easily excite people.

For example, "refactoring."

Upon hearing "refactoring," many people default to assuming it's a good thing: the code is more elegant, the architecture is clearer, the system is more modern.

But the reality is not so simple.

Some refactoring genuinely reduces complexity; other refactoring just swaps familiar complexity for unfamiliar complexity.

The old system's problem was methods that were too long and modules that were too messy; the new system's problem might become too many abstractions, call chains that are too deep, and troubleshooting that is too difficult.

On the surface, the name changed from "old code" to "new architecture." But the essential problems of the system may not have been solved.

So judging whether a refactoring is worthwhile is not about what pattern was used, nor whether the directory structure looks beautiful, but about:

Names can make people excited; results explain the reality.

8. See through the name, see the structure

This chapter seems very mystical, but it is actually very pragmatic.

It is not telling us to negate language, naming, or documentation. On the contrary, we need these things. Without names, people cannot collaborate; without definitions, systems cannot be modeled; without abstraction, complexity will crush us.

But Laozi reminds us: Use names, but do not be trapped by them.

When you see "growth," ask what is growing, why it is growing, and what the cost is. When you see "retention," ask whether users stay because of value or because of switching costs. When you see "middle platform," ask whether it is reusing capabilities or creating processes. When you see "AI capability," ask what real problem it actually solves.

The technical world is especially like this.

When you see "microservices," don't get excited first; first ask if the team has the governance capability. When you see "low-code," don't reject it first; first ask if the target users need a lower barrier to entry. When you see "DDD," don't apply the concepts first; first ask if the domain boundaries are truly clear.

All nouns are useful, but all nouns are dangerous.

Because once they become slogans, they will obscure the real problems.

9. Summary

If I were to translate the first chapter into today's working language, I would say this:

A requirements document is not the requirement, an interface name is not the interface behavior, a product metric is not user value, a technical solution is not the system itself.

We need naming, because naming makes a complex world discussable. But we also need to see through naming, because the real problem is often hidden behind the name.

A sign of a person's maturity is no longer being easily led around by words.

Hearing a concept, they ask about the scenario. Seeing a solution, they ask about the cost. Receiving a requirement, they ask about the motivation. Facing a system, they ask how it truly runs.

This is the first lesson the Dao De Jing gives to technical people:

Don't rush to define the world; first learn to see the world.

When you can take a step forward beyond the "Name," you are already standing before the "gateway to all wonders."