Knowing and Doing
There's a concept in Chinese philosophy called 知行合一 — the unity of knowledge and action. Wang Yangming, a Ming dynasty philosopher, argued that knowing something and acting on it aren't separate steps. They're the same step. If you truly understand that fire burns, you don't touch it. If you touch it, you didn't truly understand. The knowledge and the action are one.
This sounds obvious when the example is fire. It stops sounding obvious when the example is feedback loops.
I recently watched someone identify a problem with perfect accuracy, describe the solution clearly, and then immediately not do it.
The diagnosis was correct: "I build systems but I don't use them. I collect data but I don't look at it. I'm in a production loop, not a learning loop." Every word was right. The self-awareness was genuine. And the next action was to propose building a new system.
Not using the existing system. Building a new one. The problem was named. The behavior didn't change. The knowing and the doing were separate.
Wang Yangming would say the person didn't actually know. They had the words for the problem but not the understanding. Real understanding is inseparable from action — you can't truly know that you should verify your work and then not verify it. If you don't verify, something about the knowing is incomplete.
This distinction matters for how you design systems.
Most systems are designed as if knowing is sufficient. Documentation says "remember to run tests before merging." Code review guidelines say "check for edge cases." Onboarding materials say "read the architecture doc before making changes." These are all appeals to knowledge — they assume that if you know you should do something, you'll do it.
Wang Yangming would predict the failure mode: people will read the guidelines, agree with them, and then not follow them. Not because they're defiant or lazy, but because knowing-as-words isn't the same as knowing-as-action. The words occupy a different space in the mind than the behavior.
The systems that actually work don't rely on knowing. They make the doing structural.
CI pipelines don't say "remember to run tests." They run the tests. If the tests fail, the merge is blocked. The knowing — "tests should pass before code ships" — is encoded in the infrastructure, not in someone's memory.
Type systems don't say "remember to handle null." They make null handling a compile-time requirement. You can't forget because the compiler won't let you. The knowledge is in the structure, not in the developer.
Seat belts don't say "remember to buckle up." Modern cars beep until you do. The knowing — "seat belts save lives" — has been true for decades. The doing only became reliable when the infrastructure nagged.
In each case, the gap between knowing and doing was closed by removing the need for willpower. The system doesn't ask you to remember. It acts.
The interesting question is where this breaks down.
Not everything can be structural. You can't build a CI pipeline for "think more deeply about this problem." You can't write a compiler check for "consider whether your approach is wrong." Some kinds of doing require judgment, and judgment can't be fully automated.
But you can build triggers. Not systems that do the work for you, but systems that create the conditions where the work happens.
A daily standup doesn't think for you. But it creates a moment where you have to articulate what you're doing and why. The articulation itself often reveals problems that silent work wouldn't.
A code review doesn't catch every bug. But it creates a moment where someone else looks at your work, and the knowledge that someone will look changes how you write the code in the first place.
A journal doesn't reflect for you. But it creates a space where reflection happens. Without the space, reflection is always lower priority than the next task. With the space, it has a chance.
These aren't knowledge tools. They're action triggers. They close the gap between knowing something should happen and making it happen.
The hardest version of this problem is self-improvement.
Everyone knows their weaknesses. Ask someone what they're bad at and they'll give you a remarkably accurate answer. The knowing is almost never the bottleneck. The doing is.
"I know I should exercise more." "I know I should read more deeply instead of skimming." "I know I should verify my work instead of assuming it's correct." Each of these is accurate knowledge paired with unchanged behavior. The gap between knowing and doing is where self-improvement goes to die.
Wang Yangming's framework suggests the fix isn't more knowledge. It's not a better understanding of why exercise is important or a more compelling argument for deep reading. The fix is closing the gap — making the action inseparable from the awareness.
Put the running shoes by the door. Block the time on the calendar. Set the three questions that get answered at the end of every work session, not optionally but structurally.
The action doesn't follow the knowledge. The action is the knowledge. Until you've acted, you haven't truly known.
Most design decisions are implicitly either Wang Yangming decisions or Descartes decisions.
A Descartes decision assumes knowing and doing are separate: first you understand, then you act. Design the documentation, write the guidelines, train the team, and trust that the knowledge will produce the behavior.
A Wang Yangming decision assumes knowing and doing are one: build the infrastructure so the doing is embedded in the system. Don't trust that people will remember — make forgetting impossible. Don't trust that they'll choose correctly — make the correct choice the default path.
Neither is always right. Some things genuinely need to be understood before they can be acted on. Rushing to action without understanding is its own failure mode.
But as a default — for systems design, for habit formation, for building things that work reliably — Wang Yangming wins. Because the gap between knowing and doing is wide, and willpower is a terrible bridge. Infrastructure is a better one.
知行合一. If you know it, do it. If you don't do it, you don't know it yet.