Why Definitions Matter

One of the best ways to learn something is to return to its most basic definition.

Do not stop asking questions just because a concept seems like common sense: What exactly is it? Can you explain it in one sentence?

The question looks simple, but it is surprisingly difficult. We often use a word without fully understanding it. We know where it usually appears, have heard how others use it, and can imitate them. But as soon as we are asked for a definition, the gaps in our understanding become visible.

Take a Git conflict.

A conflict does not simply mean that main has moved forward, nor does it mean that both sides have modified the same file. More precisely:

When Git tries to integrate two lines of development and finds changes that it cannot merge automatically, a person must decide what the final result should be.

Suppose I change a section of code based on an older version. Meanwhile, the same section is changed on main. When Git tries to bring the two sets of changes together, it knows what each side did, but it cannot determine which result should prevail.

It cannot choose for me.

So Git stops, marks the conflicting section, and leaves the decision to me: keep the version from main, keep mine, or rework both into a third result.

Once the definition is clear, many related questions become clearer as well.

New commits on main do not necessarily cause a conflict. Nor do changes to the same file. If the changes occur in different places, or if Git can determine how they should coexist, it can still merge them automatically.

A conflict actually occurs when Git cannot automatically reconcile the changes on both sides into one definite result.

Draw the Boundary First

A good definition tells us not only what something is, but also what it is not. It helps us distinguish cases that look similar on the surface but are different in substance.

Without that boundary, we may conflate “main has been updated,” “the same file has been modified,” and “a conflict has occurred.” Then, when a problem arises, we are likely to misidentify its cause: we might assume that any commit by someone else is bound to create a conflict on our branch, or avoid changing any file that another person has touched.

The definition shows that what matters is not whether someone else made a change, but whether the changes can be merged automatically.

Give Conclusions a Starting Point

Understanding a concept means more than memorizing a sentence. It means being able to reason forward from that sentence.

If a conflict means that Git cannot automatically decide the final result, then resolving one is not fundamentally about removing a few special markers. It is about making the judgment that Git cannot make. You need to understand what problem each side was trying to solve, then decide what the final code should look like.

We can reason further from there: code that compiles does not prove that the conflict was resolved correctly; deleting everything from one side is not necessarily the right answer; and the disappearance of conflict markers shows only that Git accepted your choice, not that the choice preserves the code’s original intent.

There is no need to memorize these conclusions one by one. Once you understand the definition, you can derive them from it.

Much of what we know feels fragmented because we remember a large number of conclusions without finding the point from which they follow. A definition is like the root of a tree. The more firmly it takes hold, the easier it becomes to fit new problems into the same structure of understanding.

Make Sure We Mean the Same Thing

Many disagreements appear to be about conclusions, when the people involved are actually using the same word to mean different things.

One person calls a product “simple” because it has few features. Another means that it is easy to understand on first use. A third means that it requires little recurring maintenance over time. All three are talking about “simplicity,” but not about the same thing.

There are many words like this: efficiency, quality, done, stability, risk, freedom, and fairness.

The more familiar these words are, the easier it is to assume that everyone already understands one another. But once the discussion becomes concrete, the differences hidden behind the words begin to emerge. When one person says, “This feature is done,” they may mean only that the code has been written. To someone else, done includes testing, documentation, deployment, and monitoring.

If we do not clarify the definition first, the gap may widen as the discussion goes deeper.

That is why, in an important discussion, asking “What exactly do you mean by that word?” is not pedantry. It is a way to make sure both sides are standing on the same ground.

Do You Really Understand It?

A vague understanding often feels reassuring. As long as we do not have to explain it, it is easy to believe that we understand.

Defining something forces us to make choices: Which characteristics are essential, and which merely tend to accompany it? Which cases should be included, and which excluded? If a condition is removed, does the concept still hold?

This is why explaining something in your own words is an effective way to learn. The point is not to rephrase the original text, but to test whether you can identify the indispensable parts of the concept.

Of course, explaining something in one sentence does not mean cramming all of its complexity into that sentence.

A definition is not a complete account of reality, but a doorway into it. It must be concise enough to reveal the core and accurate enough to preserve important distinctions. A definition that is too broad cannot distinguish one thing from another; one that is too narrow excludes real cases.

More importantly, definitions have a scope in which they apply.

A “conflict” in everyday conversation is not the same as a “conflict” in Git. Law, mathematics, and philosophy may each define the same word differently. We cannot remove a word from its context and search for a single statement that is always correct in every setting.

Do Not Mistake a Definition for the Answer

A definition is not the end of a discussion, nor can it replace observation, practice, and judgment. The real world often contains edge cases, and old definitions may be revised as knowledge develops. The value of a definition is not that it fixes something complex in place forever, but that it gives our present thinking a clear, testable starting point.

When a question becomes confused, it helps to take a step back: What exactly is the thing we are talking about?

Many problems will not disappear simply because we find a definition. But with one, we at least know what we are discussing, where the problem lies, and in which direction to think next.

That is already an important beginning to understanding something.