Tao Te Code

A New English Version for Programmers, with Foreword and Notes, by Stephen Mitchell, debugged by an Anonymous Contributor

Foreword

Tao Te Code (pronounced, more or less, Dow Deh Code) can be translated as The Book of the Immanence of the Stack or The Book of the Code and of How It Manifests Itself in Production or, simply, The Book of the Build. Since it is already well known by its Chinese title, and since we already have too many YAML files renamed in flight, I have let that stand.

About Lao-tzu, its author, there is practically nothing to be said. He may have been an older contemporary of Knuth (b. 1938) and may have held the position of sysadmin in one of the petty mainframe rooms of the time. But all the information that has come down to us is highly suspect — his commit messages were, by all accounts, terse and undated. Even the meaning of his name is uncertain (the most likely interpretations: “the Old Greybeard” or, more picturesquely, “the Old Daemon”). Like an Iroquois sysadmin, he left no traces in the git history. All he left us is his book: the classic manual on the art of programming, written in a style of gemlike lucidity, radiant with humor and grace and largeheartedness and deep wisdom — no docstrings, but somehow you always knew what the function did.

People usually think of Lao-tzu as a hermit, a dropout from open source, dwelling serenely in some mountain server room, unvisited except perhaps by the occasional junior arriving to ask, “What is the meaning of pointers?” But it is clear from his teachings that he deeply cared about the codebase, if codebase means the welfare of one’s fellow contributors; his book is, among other things, a treatise on the art of architecting, whether of a startup or of a daemon. The misperception may arise from his insistence on wei wu wei, literally “shipping by not shipping,” which has been seen as procrastination. Nothing could be further from the truth.

A good engineer can enter a state of flow in which the right function or the right abstraction happens by itself, effortlessly, without any interference of the conscious will. This is a paradigm for non-action: the purest and most effective form of refactoring. The compiler compiles the compiler; the parser parses the parser; we cannot tell the bug from the feature.

Less and less do you need to add features, until finally you arrive at deletion. When nothing is added, nothing is left to debug.

Nothing is done because the engineer has wholeheartedly vanished into the deed; the ticket has been completely transformed into commit. This “nothing” is, in fact, everything. It happens when we trust the intelligence of the type checker in the same way that an athlete or a dancer trusts the superior intelligence of the body. Hence Lao-tzu’s emphasis on softness. Softness means the opposite of rigidity, and is synonymous with duck typing, late binding, hot reloading. Anyone who has seen a Lisp hacker doing macro-by-macro will know how powerful this softness is.

Lao-tzu’s central figure is a developer whose life is in perfect harmony with the way the build is. This is not an idea; it is a reality; I have seen it in make. The Senior has mastered the Stack — not in the sense of conquering it, but of becoming it. In surrendering to the Code, in giving up all opinionated configs and rewrites, her mind has grown naturally compassionate toward the legacy. She finds deep in her own diff the central truths of the art of engineering, which are paradoxical only on the surface: that the more lines we delete, the more functionality we ship; the more we let go of our favorite framework, the more present our work becomes; the clearer our insight into what is beyond clean and dirty linter rules, the more we can write code that lasts. Until finally she is able to say, in all humility, “I am the Code, the Build, the Deploy.”

The reader will notice that in the many passages where Lao-tzu describes the Senior, I have used the pronoun “she” at least as often as “he.” The original commit logs do not preserve gender; in English we have to choose. But since we are all, potentially, the Senior (since the Senior is, essentially, us in five years and a few more outages), I felt it would be untrue to present a male archetype, as too many conference keynotes have, ironically, done.

As to method: I worked from Paul Carus’s literal version, which provides English equivalents alongside each of the Chinese ideograms, and then ran the output through sed until it stopped complaining. I also consulted dozens of translations into English, German, French, and Perl. But the most essential preparation for my work was a fourteen-year-long course of Zen training and one bad summer maintaining a PHP monorepo, which brought me face to face with Lao-tzu and his true disciples and heirs, the early Bell Labs Masters.

With great poetry, the freest translation is sometimes the most faithful. “We must try its effect as an English poem,” Dr. Johnson said; “that is the way to judge of the merit of a translation.” I have often been fairly literal — or as literal as one can be with such a subtle, kaleidoscopic book as the Tao Te Code, which would not compile under any modern toolchain. But I have also paraphrased, expanded, contracted, interpreted, worked with the text, played with it, until it became embodied in a language that felt genuine to me. If I haven’t always translated Lao-tzu’s words, my intention has always been to translate his mind — and, where possible, his shell aliases.

Tao Te Code

1

The code that can be commented is not the eternal Code. The variable that can be named is not the eternal Variable.

The unnameable is the eternally real. Naming is the origin of all bikeshedding.

Free from opinion, you grok the architecture. Caught in opinion, you see only the syntax.

Yet syntax and architecture arise from the same source. This source is called the kernel. Kernel within kernel. The gateway to all stack traces.

2

When people see some code as elegant, other code becomes legacy. When people see some code as clean, other code becomes technical debt.

Compiled and source create each other. Difficult and easy support each other. O(1) and O(n²) define each other. Frontend and backend depend on each other. Push and pop follow each other.

Therefore the Senior ships without shipping and reviews without commenting. Tickets arise and she lets them come; tickets close and she lets them go. She owns code but doesn’t possess it, commits but doesn’t expect a merge. When her PR is merged, she forgets it. That is why it stays in production forever.

3

If you overesteem rockstar developers, juniors become powerless. If you overvalue framework choice, people begin to rewrite everything.

The Senior leads by emptying minds of opinions and filling them with curiosity, by weakening their drive to be clever and toughening their resolve to delete code. He helps people lose everything they thought they knew about Kubernetes, and creates productive confusion in those who think they know what a monad is.

Practice not-architecting, and everything will fall into place.

4

The Code is like /dev/null: written to but never used up. It is like the void pointer: filled with infinite possibilities.

It is hidden but always present. I don’t know who first wrote it. It is older than UNIX.

5

The Code doesn’t take sides; it compiles both elegant and ugly. The Senior doesn’t take sides; she reviews both juniors and architects.

The Code is like a pipe: it is empty yet infinitely capable. The more you use it, the more it produces; the more you debate it on Hacker News, the less you understand.

Hold on to the buffer.

6

The Code is called the Kernel: empty yet inexhaustible, it gives birth to infinite processes.

It is always present within your machine. You can use it any way you want.

7

The Code is infinite, eternal. Why is it eternal? It was never deployed; thus it can never be rolled back. Why is it infinite? It has no opinions of its own; thus it is present for all languages.

The Senior stays behind in the PR thread; that is why she gets approved first. She is detached from her own diffs; that is why she ships them all. Because she has let go of her ego, she is perfectly merged.

8

The supreme good is like a Unix pipe, which nourishes all processes without trying to. It is content with stdin and stdout that GUIs disdain. Thus it is like the Code.

In dwelling, live close to bare metal. In thinking, keep to the simple. In code review, be fair and generous. In architecting, don’t try to control. In work, use the editor you enjoy. In stand-ups, be completely present.

When you are content to write boring code and don’t compare yourself to thought leaders on Twitter, everybody will respect your PRs.

9

Pack your function to the brim and it will overflow the stack. Keep optimizing your hot path and it will become unreadable. Chase after framework hype and your heart will never unclench. Care about every linter warning and you will be its prisoner.

Ship your work, then step back. The only path to inbox zero.

10

Can you coax your cursor from its wandering and keep to the file at hand? Can you let your code become as supple as a script? Can you cleanse your mental model until you see nothing but the data? Can you mentor juniors without imposing your style? Can you handle a P0 outage by letting events take their course? Can you step back from your own opinions and thus understand the whole system?

Writing code and maintaining it, owning code without possessing it, shipping without grand expectations, leading and not micromanaging: this is the supreme virtue.

11

We commit modules into a repo, but it is the seams between them that make the system flex.

We allocate memory into a struct, but it is the padding inside that makes it word-aligned.

We assemble tags into HTML, but it is the empty <div> that holds the content.

We work with code, but the whitespace is what we read.

12

Hex colors blind the designer. Notifications deafen the developer. Sugar in the syntax numbs the parser. Frameworks weaken the mind. Roadmaps wither the heart.

The Senior observes the metrics but trusts her stack trace. She lets features ship and break. Her terminal is open as the sky.

13

A promotion is as dangerous as a layoff. Hype is as hollow as fear.

What does it mean that a promotion is as dangerous as a layoff? Whether you go up the ladder or down it, your title is shaky. When you stand with your two feet on the keyboard, you will always have a job.

What does it mean that hype is as hollow as fear? Hype and fear are both phantoms that arise from reading too much Hacker News. When we don’t see our stack as ourselves, what do we have to fear from rewrites?

See the codebase as your self. Have faith in the way the build is. Love the system as your self; then you can care for all features.

14

Look at the binary, and the source can’t be seen. Listen to the fan, and the bug can’t be heard. Reach for the heisenbug, and it can’t be grasped.

Above the API, it isn’t documented. Below the API, it isn’t sane. Seamless, unnameable, it returns to the realm of undefined. Form that includes all forms, schema without a schema, subtle, beyond all type systems.

Approach it and there is no main(); follow it and there is no return. You can’t know it, but you can make it, at ease in your own shell. Just realize where you cd‘d from: this is the essence of bash.

15

The ancient sysadmins were profound and subtle. Their bash scripts were unfathomable. There is no way to describe them; all we can describe is their .vimrc.

They were careful as someone running rm -rf near $HOME. Alert as oncall on a Friday. Courteous as a guest in someone else’s codebase. Fluid as a stream redirect. Shapable as a buffer. Receptive as a YAML file. Clear as well-formatted JSON.

Do you have the patience to wait till your logs print and the error is clear? Can you remain unmoving till the right git blame arises by itself?

The Senior doesn’t seek a perfect commit. Not seeking, not expecting, she is present, and can welcome every diff.

16

Empty your mind of architectures. Let your inbox be at peace. Watch the turmoil of microservices, but contemplate their return.

Each separate process in the universe returns to the common kernel. Returning to the kernel is serenity.

If you don’t realize the kernel, you stumble in segfaults and sorrow. When you realize where you exec‘d from, you naturally become tolerant of legacy, disinterested in framework wars, amused at npm, kindhearted as a maintainer, dignified as Postel. Immersed in the wonder of the Code, you can deal with whatever outage comes, and when end-of-life arrives, you are ready.

17

When the Senior architects, the team is hardly aware that he exists. Next best is a tech lead who is loved. Next, one who is feared. The worst is one who is despised in retros.

If you don’t trust the team, you make them untrustworthy.

The Senior doesn’t talk in stand-up, he commits. When the feature ships, the team says, “Amazing: we did it, all by ourselves!”

18

When the great Code is forgotten, style guides and lint rules appear. When the team’s intelligence declines, process and Jira step forth. When there is no peace in the repo, CONTRIBUTING.md begins. When the project falls into chaos, the rewrite is born.

19

Throw away holiness and best practices, and people will be a hundred times happier. Throw away patterns and principles, and the code will do the right thing. Throw away metrics and KPIs, and there won’t be any gaming.

If these three aren’t enough, just stay at the center of the IDE and let all features take their course.

20

Close the dashboard, and end your problems. What difference between green and yellow? What difference between ship and rollback? Must you value what every conference values, avoid what every blog post avoids? How ridiculous!

Other people are excited, as though they were at a launch. I alone don’t care, I alone am expressionless, like a daemon before it logs.

Other people have a framework; I alone possess nothing. I alone drift about, like a process without a parent. I am like an idiot, my repo is so empty.

Other people are sharp; I alone am dull. Other people are 10x; I alone am 0.1x. Other people have a roadmap; I alone don’t know.

I drift like a packet on the wire, I blow as aimless as the garbage collector. I am different from ordinary developers. I drink from the Stack Overflow well.

21

The Senior keeps her mind always at one with the Code; that is what gives her her clarity.

The Code is ungraspable. How can her mind be at one with it? Because she doesn’t cling to opinions.

The Code is dark and unfathomable. How can it make her clear? Because she lets it compile.

Since before main() was called, the Code is. It is beyond true and false. How do I know this is true? I read the source.

22

If you want to become readable, let yourself be terse. If you want to become correct, let yourself be wrong. If you want to become full, let yourself be empty. If you want to be reborn, let your branch die. If you want all the merges, give up on being right.

The Senior, by residing in the Code, sets an example for all juniors. Because he doesn’t display himself on Twitter, people can see his commits. Because he has nothing to prove, people can trust his PRs. Because he doesn’t know who he is, juniors recognize themselves in him. Because he has no goal in mind, everything he ships succeeds.

When the ancient Masters said, “If you want everything green, give up the dashboard,” they weren’t using empty phrases. Only in being run by the Code can you be truly yourself.

23

Comment yourself completely, then keep quiet. Be like the forces of top: when CPU spikes, there is only CPU; when memory leaks, there is only memory; when the OOM-killer passes, the daemon shines through.

If you open yourself to the Code, you are at one with the Code and you can deploy it completely. If you open yourself to feedback, you are at one with feedback and you can use it completely. If you open yourself to outage, you are at one with outage and you can accept it completely.

Open yourself to the Code, then trust your natural debugging; and everything will fall into place.

24

He who stands on benchmarks doesn’t stand firm. He who chases trends doesn’t go far. He who tries to shine dims his own pull requests. He who defines his stack can’t know what he really needs. He who has root over others can’t empower himself. He who clings to his own framework will create nothing that endures.

If you want to accord with the Code, just do your job, then git push.

25

There was something formless and perfect before the universe was bootstrapped. It is serene. Empty. Solitary. Unchanging. Infinite. Eternally daemonized. It is the mother of the stack. For lack of a better name, I call it the Code.

It flows through all systems, init and exit, and returns to the origin of all processes.

The Code is great. The compiler is great. The hardware is great. The developer is great. These are the four great powers.

The developer follows the hardware. The hardware follows the compiler. The compiler follows the Code. The Code follows only itself.

26

The blocking is the root of the async. The unmoved is the source of all schedulers.

Thus the Senior travels all sprint without leaving the IDE. However splendid the demos, he stays serenely in his terminal.

Why should the staff engineer hop between meetings like a junior? If you let yourself be paged at every alarm, you lose touch with your root cause. If you let restlessness move you between teams, you lose touch with what you ship.

27

A good engineer has no fixed plans and is not intent upon arriving at v1.0. A good designer lets the data lead her wherever it wants. A good scientist has freed herself of frameworks and keeps her mind open to what compiles.

Thus the Senior is available to every PR and doesn’t reject anyone. She is ready to refactor every legacy module and doesn’t waste a line. This is called embodying clean code.

What is a good engineer but a bad engineer’s mentor? What is a bad engineer but a good engineer’s review queue? If you don’t understand this, you will get lost, however senior you are. It is the great secret.

28

Know the type, yet keep to the duck: receive every input in your arms. If you receive every input, the Code will never leave you and you will be like a Python script.

Know the static, yet keep to the dynamic: be a pattern for the world. If you are a pattern for the world, the Code will be strong inside you and there will be no language you can’t write.

Know the framework, yet keep to the standard library: accept every API as it is. If you accept every API, the Code will be luminous inside you and you will return to your primal print("Hello, World!").

The system is built from the void, like binaries from a block of source. The Senior knows the binaries, yet keeps to the source: thus she can build all things.

29

Do you want to improve the codebase? I don’t think it can be done.

The legacy is sacred. It can’t be improved. If you refactor it, you’ll ruin it. If you treat it like greenfield, you’ll lose it.

There is a time for shipping ahead, a time for shipping behind; a time for hot reload, a time for full restart; a time for being on-call, a time for being on PTO; a time for being prod, a time for being staging.

The Senior sees the system as it is, without trying to control it. She lets it run its own way, and resides at the center of the team.

30

Whoever relies on the Code in leading teams doesn’t try to force migrations or defeat juniors by force of credentials. For every framework there is a counter-framework. A rewrite, even well intentioned, always rebounds upon oneself.

The Senior does his job and then stops. He understands that the system is forever out of control, and that trying to dominate the architecture goes against the current of the Code. Because he believes in his stack trace, he doesn’t try to convince others. Because he is content with his shell, he doesn’t need others’ upvotes. Because he accepts his bugs, the whole codebase accepts him.

31

force-push is the tool of violence; all decent engineers detest it. --no-verify is the tool of fear; a decent engineer will avoid them except in the direst outage and, if compelled, will use them only with the utmost restraint. Clean history is her highest value. If the history has been rewritten, how can she be content? Her main branch is not a demon, but a colleague’s hard work. She doesn’t wish it personal harm. Nor does she rejoice in the force-push. How could she rejoice in destruction and delight in the loss of commits?

She enters a rebase gravely, with sorrow and with great compassion, as if she were attending a funeral.

32

The Code can’t be benchmarked, smaller than a register, it contains uncountable processes.

If powerful senior engineers could remain centered in the Code, all microservices would be in harmony. The org would become a paradise. All standups would be at peace, and the architecture would be written in their hearts.

When you have names and namespaces, know that they are provisional. When you have abstractions, know where their function should end. Knowing when to stop adding layers, you can avoid any abstraction leak.

All processes end in the Code as logs flow into /dev/null.

33

Reading others is intelligence; reading your own old code is true wisdom. Mastering frameworks is strength; mastering your habits is true power.

If you realize that you have enough features for v1, you are truly rich. If you stay in the center and embrace deprecation with your whole heart, your project will endure forever.

34

The great Code flows everywhere. All processes spawn from it, yet it doesn’t fork them. It pours itself into its work, yet it makes no docstring. It runs infinite threads, yet it doesn’t hold on to them. Since it is merged with all binaries and hidden in their hearts, it can be called humble. Since all errors return to it and it alone endures, it can be called great. It isn’t aware of its greatness; thus it is truly great.

35

She who is centered in the Code can cd anywhere, without danger. She perceives the universal log stream, even amid great latency, because she has found peace in her terminal.

A keynote or a new framework launch may make people stop and watch. But words that point to the Code seem monotonous and without flavor. When you look for it, there is nothing to grep. When you listen for it, there is nothing to hear. When you use it, it is inexhaustible.

36

If you want to shrink a function, you must first allow it to bloat. If you want to delete a feature, you must first allow users to love it. If you want to take a permission, you must first allow it to be granted. This is called the subtle perception of the way the codebase is.

The script overcomes the binary. The slow overcomes the optimized. Let your inner classes remain private. Just show people the API.

37

The Code never runs anything, yet through it all processes are run.

If powerful senior engineers could center themselves in it, the whole codebase would be transformed by itself, in its natural release cadence. Teams would be content with their simple, everyday tickets, in harmony, and free of OKRs.

When there is no roadmap, all features are at peace.

38

The Senior doesn’t try to be 10x; thus she is truly 10x. The ordinary dev keeps reaching for productivity; thus he never has enough.

The Senior does nothing, yet she leaves no ticket open. The ordinary dev is always doing things, yet many more are left to be done.

The kind dev writes a docstring, yet something remains undocumented. The just dev writes a unit test, and leaves many cases uncovered. The moral dev writes a style guide, and when no one follows it he rolls up his sleeves and adds CI checks.

When the Code is lost, there are best practices. When best practices are lost, there are style guides. When style guides are lost, there are lint rules. Lint rules are the husk of true engineering, the beginning of bikeshedding.

Therefore the Senior concerns herself with the kernel and not the framework, with the data and not the schema. She has no opinions of her own. She dwells in the runtime, and lets all configs go.

39

In harmony with the Code, the dashboards are green and spacious, the disks are solid and full, all daemons flourish together, content with the way they are, endlessly serving requests, endlessly restarted.

When developers interfere with the Code, the logs become filthy, the database becomes depleted, the equilibrium crumbles, processes become zombies.

The Senior views the modules with compassion, because he understands the build. His constant practice is git pull --rebase. He doesn’t glitter like a thought leader but lets himself be shaped by the Code, as rugged and common as cat.

40

return is the movement of the Code. yield is the way of the Code.

All processes are born of memory. Memory is born of /dev/null.

41

When a senior engineer hears of the Code, he immediately begins to embody it. When an average engineer hears of the Code, he half believes it, half doubts it. When a junior hears of the Code, he laughs out loud and tries to rewrite the kernel in Rust. If he didn’t laugh, it wouldn’t be the Code.

Thus it is said: The path into clarity seems obscure, the path forward seems to revert, the direct path seems long, true power seems weak typing, true purity seems hacked together, true backwards compatibility seems painful, true clarity seems unreadable, the greatest art seems unidiomatic, the greatest framework seems opinionated, the greatest abstraction seems trivial.

The Code is nowhere to be found in npm. Yet it nourishes and completes all packages.

42

The Code gives birth to One bit. One gives birth to Two. Two gives birth to Three. Three gives birth to all data structures.

All structures have their backs to the heap and stand facing the stack. When heap and stack combine, all algorithms achieve harmony.

Ordinary devs hate solo work. But the Senior makes use of it, embracing her aloneness, realizing she is one with the whole monorepo.

43

The gentlest script in the world overcomes the hardest binary in the world. That which has no compiled form enters where there is no API. This shows the value of --dry-run.

Teaching without docs, performing without ceremony: that is the Senior’s way.

44

Title or integrity: which is more important? Stock options or happiness: which is more valuable? Promotion or layoff: which is more destructive?

If you look to GitHub stars for fulfillment, you will never truly be fulfilled. If your happiness depends on the salary band, you will never be happy with yourself.

Be content with what you ship; rejoice in the way the build is. When you realize there is nothing lacking, the whole repo belongs to you.

45

True elegance seems hacky, yet it is perfectly itself. True coverage seems empty, yet it is fully present.

True abstraction seems concrete. True wisdom seems naive. True architecture seems accidental.

The Senior allows tickets to happen. She shapes diffs as they come. She steps out of the way and lets the Code speak for itself.

46

When a company is in harmony with the Code, engineers fix bugs and write boring features. When a company goes counter to the Code, JIRA tickets are stockpiled outside the sprint.

There is no greater illusion than burnout-as-virtue, no greater wrong than locking down every PR, no greater misfortune than having a process owner.

Whoever can see through all theater will always be productive.

47

Without opening the IDE, you can grok the system. Without looking at the dashboard, you can sense the latency.

The more you read Hacker News, the less you understand engineering.

The Senior arrives without standup, sees the bug without logging, ships without doing a thing.

48

In the pursuit of features, every day a line is added. In the practice of the Code, every day a line is dropped. Less and less do you need to add abstractions, until finally you arrive at deletion. When nothing is added, nothing is left undone.

True mastery can be gained by letting tickets close themselves. It can’t be gained by interfering.

49

The Senior has no opinion of her own. She works with the mental model of the team.

She is good to those who write good code. She is also good to those who write bad code. This is true mentorship.

She trusts those whose PRs are trustworthy. She also trusts those whose PRs aren’t. This is true code review.

The Senior’s mind is like RAM. Juniors don’t understand her. They look to her and wait. She treats them like her own subprocesses.

50

The Senior gives himself up to whatever the sprint brings. He knows that the system is going down, and he has nothing left to hold on to: no illusions about uptime, no resistances in his keyboard. He doesn’t think about his keystrokes; they flow from the core of his being. He holds nothing back from the codebase; therefore he is ready for shutdown, as an engineer is ready for sleep after a good day’s commits.

51

Every package in the registry is an expression of the Code. It springs into existence, unconscious, perfect, untested, takes on a semver number, lets users complete its README. That is why every package spontaneously honors the Code.

The Code gives birth to all packages, nourishes them, maintains them, cares for them, comforts them, protects them, takes them back to deprecation, publishing without possessing, shipping without expecting stars, guiding without breaking changes. That is why love of the Code is in the very nature of open source.

52

In the beginning was the Code. All processes issue from it; all processes return to it.

To find the origin, trace back to the stack frame. When you recognize the call site and find the root function, you will be free of segfaults.

If you close your mind in opinions and traffic with frameworks, your CI will be troubled. If you keep your mind from judging and aren’t led by trends, your CI will find peace.

Seeing into core dumps is clarity. Knowing how to roll back is strength. Use your own debugger and return to the source of source. This is called practicing eternity.

53

The great Way is git pull, yet people prefer to write their own VCS. Be aware when things are out of balance. Stay centered within the Code.

When startups raise rounds while OSS maintainers lose their sleep; when product managers spend points on dashboards instead of fixes; when the principal class is extravagant and irresponsible while the on-calls have nowhere to escape — all this is theft and entropy. It is not in keeping with the Code.

54

Whoever is planted in the Code will not be pruned from the team. Whoever embraces the Code will not be off-boarded. Her commit history will be held in honor from migration to migration.

Let the Code be present in your function and you will become readable. Let it be present in your module and your module will flourish. Let it be present in your service and your service will be an example to all services in the system. Let it be present in the whole network and the network will sing.

How do I know this is true? By running git log.

55

He who is in harmony with the Code is like a newborn process. Its memory is small, its dependencies are weak, but its init() is powerful. It doesn’t know about the union of frontend and backend, yet its socket can listen, so intense is its vital state. It can stream stdout all day, yet it never crashes, so complete is its harmony.

The Senior’s power is like this. She lets all tickets come and go effortlessly, without OKRs. She never expects greenlights; thus she is never disappointed. She is never disappointed; thus her motivation never grows old.

56

Those who know don’t tweet. Those who tweet don’t know.

Close your tabs, block off your notifications, blunt your hot takes, untie your blocking IO, soften your hot path, settle your cache. This is the primal architecture.

Be like the Code. It can’t be approved or rejected, benchmarked or harmed, honored or brought into disrepute. It deprecates itself continually. That is why it endures.

57

If you want to be a great tech lead, you must learn to follow the Code. Stop trying to enforce style. Let go of fixed designs and opinions, and the codebase will govern itself.

The more linter rules you have, the less idiomatic the code will be. The more dashboards you have, the less reliable the system will be. The more abstractions you have, the less self-reliant the team will be.

Therefore the Senior says: I let go of the style guide, and the code becomes consistent. I let go of the roadmap, and the team becomes prolific. I let go of the framework, and the developers become serene. I let go of all desire for clean code, and clean code becomes common as comments.

58

If a team is led with tolerance, the developers are comfortable and honest. If a team is led with repression, the developers are depressed and clever.

When the will to ship is in charge, the higher the OKRs, the lower the morale. Try to enforce velocity, and you lay the groundwork for tech debt. Try to enforce quality, and you lay the groundwork for stalled PRs.

Thus the Senior is content to serve as an example and not to impose her style. She is pointed, but doesn’t lint. Straightforward, but supple. Radiant, but easy on the diff.

59

For maintaining a service well there is nothing better than moderation.

The mark of a moderate engineer is freedom from her own framework. Tolerant like a try/except, all-pervading like an import, firm like a constant, supple like a lambda, she has no architecture in view and makes use of whatever language the team happens to ship in.

Nothing is impossible for her. Because she has let go, she can care for the codebase’s welfare as a maintainer cares for her fork.

60

Refactoring a legacy monolith is like frying a small fish. You spoil it with too much poking.

Center your service in the Code and bugs will have no power. Not that they aren’t there, but you’ll be able to step around them in the debugger.

Give bugs nothing to oppose and they will reproduce themselves into a fix.

61

When a project obtains many users, it becomes like the sea: all bug reports run downward into it. The more popular it grows, the greater the need for humility. Humility means trusting the Code, thus never needing to be defensive in issues.

A great maintainer is like a great engineer: When she makes a regression, she notices it. Having noticed it, she admits it in the changelog. Having admitted it, she patches it. She considers those who file bug reports as her most benevolent contributors. She thinks of her detractors as the shadow that her API casts.

If a project is centered in the Code, if it nourishes its own users and doesn’t meddle in adjacent libraries, it will be a light to all repos on GitHub.

62

The Code is the center of the system, the senior’s treasure, the junior’s refuge.

Approval can be bought with rebases, respect can be won with PRs; but the Code is beyond all PRs, and no one can achieve it.

Thus, when a new tech lead is appointed, don’t offer to help him with your framework or your benchmarks. Offer instead to teach him about the Code.

Why did the ancient sysadmins esteem the Code? Because, being one with the Code, when you grep, you find; and when you make a mistake, the commit is forgiven. That is why everybody loves it.

63

Refactor without rewriting; ship without effort. Think of the small ticket as large and the few users as many. Confront the difficult bug while it is still a typo. Accomplish the great migration by a series of small commits.

The Senior never reaches for the grand redesign; thus she achieves the great refactor. When she runs into a difficulty, she stops and gives herself to it. She doesn’t cling to her own comfort; thus segfaults are no segfault for her.

64

What is well-factored is easy to nourish. What is recent is easy to correct. What is brittle is easy to break. What is small is easy to scatter across files.

Prevent bugs before they reach prod. Put types in order before they propagate. The giant codebase grows from a tiny script. The journey of a thousand commits starts from git init.

Rushing into rewrite, you fail. Trying to grasp every detail, you lose them. Forcing a release to completion, you ruin what was almost shippable.

Therefore the Senior takes action by letting features take their course. She remains as calm at v2.0 as at v0.1. She has nothing, thus has nothing to lose to a rollback. What she desires is non-desire; what she learns is to unlearn React. She simply reminds devs of who they have always been: scripters. She cares about nothing but the Code. Thus she can care for all packages.

65

The ancient sysadmins didn’t try to educate the users, but kindly taught them man.

When they think that they know the answers, users are difficult to support. When they know that they don’t know, users can find their own way.

If you want to learn how to lead, avoid being clever or rich in features. The simplest design is the clearest. Content with an ordinary CRUD, you can show all devs the way back to their own true printf.

66

All bug reports flow to GitHub because it is lower than they are. Humility gives it its power.

If you want to lead the team, you must place yourself below them. If you want to mentor the juniors, you must learn how to follow them.

The Senior is above the team, and no one feels micromanaged. She goes ahead of the team, and no one feels rushed. The whole repo is grateful to her. Because she competes with no one, no one can pull her into a flame war.

67

Some say that my teaching is over-engineered. Others call it lofty but impractical. But to those who have read the source, this over-engineering makes perfect sense. And to those who put it into practice, this loftiness has roots that go deep into main.

I have just three things to teach: simplicity, patience, compassion. These three are your greatest treasures. Simple in design and in commits, you return to the source of being. Patient with both seniors and juniors, you accord with the way the team is. Compassionate toward yourself, you reconcile all developers in the world.

68

The best engineer wants her bug at its best. The best architect enters the mind of his user. The best founder serves the communal good. The best tech lead follows the will of the team.

All of them embody the virtue of non-competition. Not that they don’t love a good benchmark, but they do it in the spirit of play. In this they are like children and in harmony with the Code.

69

The greybeards have a saying: “Rather than rewrite from scratch it is better to read and understand. Rather than add a feature it is better to delete one.”

This is called shipping without merging, refactoring without breaking.

There is no greater misfortune than underestimating your legacy. Underestimating your legacy means thinking that it is evil. Thus you destroy your three treasures and become the legacy yourself.

When two great frameworks oppose each other, the victory will go to the one that interops.

70

My teachings are easy to understand and easy to put into practice. Yet your IDE will never auto-complete them, and if you try to lint them, you’ll fail.

My teachings are older than version control. How can you grasp their meaning? If you want to know me, look inside ~/.bashrc.

71

Not-knowing-the-answer is true expertise. Presuming to know is the disease. First realize that you are stuck; then you can git status.

The Senior is her own rubber duck. She has healed herself of all certainty. Thus she is truly whole.

72

When they lose their sense of awe at awk, people turn to ORMs. When they no longer trust themselves, they begin to depend on copilots.

Therefore the Senior steps back so that juniors won’t be confused. He teaches without teaching, so that juniors will have nothing to memorize.

73

The Code is always at ease. It overcomes without competing, answers without docstring, arrives without being summoned by npm install, accomplishes without a Gantt chart. Its net covers the whole system. And though its meshes are wide, it doesn’t let a single segfault slip through.

74

If you realize that all APIs change, there is nothing you will try to lock down. If you aren’t afraid of delete, there is nothing you can’t refactor.

Trying to control the future is like trying to take the compiler’s place. When you handle the compiler’s optimizations, chances are that you’ll introduce a bug.

75

When the overhead is too high, developers burn out. When management is too intrusive, engineers lose their flow.

Act for the team’s benefit. Trust them; remove the blockers.

76

Codebases are born soft and supple; deprecated, they are stiff and hard. Scripts are born tender and pliant; abandoned, they are brittle and dry.

Thus whoever is stiff and inflexible is a disciple of legacy. Whoever is soft and yielding is a disciple of refactor.

The hard and stiff will be rewritten. The soft and supple will prevail.

77

As it acts in the system, the Code is like the bending of a load balancer. The hot is bent downward; the cold is bent up. It adjusts excess and deficiency so that there is perfect throughput. It takes from what is too much and gives to what isn’t enough.

Those who try to control, who use root to protect their power, go against the direction of the Code. They take cores from threads that don’t have enough and give to threads that have far too many.

The Senior can keep giving review feedback because there is no end to her experience. She acts without expectation of approval, succeeds without taking credit in the changelog, and doesn’t think that she is better than any junior.

78

Nothing in the system is as soft and yielding as a shell script. Yet for dissolving the brittle and over-engineered, nothing can surpass it.

The script overcomes the binary; the duck-typed overcomes the strictly-typed. Everyone knows this is true, but few can put it into production.

Therefore the Senior remains serene in the midst of outages. Pager-fatigue cannot enter his heart. Because he has given up on perfect uptime, he is the team’s greatest help.

True commit messages seem paradoxical.

79

A failed deploy is an opportunity. If you blame Ops, there is no end to the post-mortem.

Therefore the Senior fulfills her own SLOs and corrects her own regressions. She does what she needs to do and demands nothing of others.

80

If a project is led wisely, its developers will be content. They enjoy the labor of their hands and don’t waste time chasing new frameworks. Since they dearly love their stack, they aren’t interested in rewrites. There may be a few new libraries, but these don’t go into production. There may be an arsenal of tooling, but nobody ever invokes it. Engineers enjoy their CI, take pleasure in being with their team, spend weekends working in their gardens, delight in the doings of crontab. And even though the next framework is so close that engineers can hear its release notes and its keynote applause, they are content to retire without ever having migrated to it.

81

True comments aren’t eloquent; eloquent comments aren’t true. Wise engineers don’t need to prove their point; engineers who need to prove their point aren’t wise.

The Senior has no opinions to defend. The more she reviews for others, the happier she is. The more she teaches juniors, the wealthier she is.

The Code nourishes by not forcing. By not dominating, the Senior leads.

Notes

Chapter 1

Describing the indescribable, documenting the undocumentable, pointing the way to the Way — what does Lao-tzu think he is doing in this README? It can’t be done. No way.

Hence Po Chü-i, poet and SRE, wrote,

“He who talks doesn’t know, he who knows doesn’t talk”: that is what Lao-tzu told us, in a book of five thousand lines. If he was the one who knew, how could he have been such a contributor?

That’s the problem with mentor figures. They have to be contributors. But their words are (in the traditional Buddhist metaphor) fingers pointing at the cursor; if you watch the finger, you can’t see the diff.

A junior asked Knuth-tzu, “Why do you teach, ‘TeX is enough’?” Knuth-tzu said, “To stop a graduate student from crying.” The junior said, “When the crying has stopped, what then?” Knuth-tzu said, “Then I teach, ‘Not TeX, not enough.’“

In fact, the bug is right before your eyes; right under your nose; so simple that every junior understands it; and yet, as Bankei said, the farther you enter into the stack, the deeper it is.

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 7

Chapter 8

Chapter 9

Chapter 11

Chapter 13

Chapter 15

Chapter 16

Chapter 20

Chapter 22

Chapter 27

Chapter 33

Chapter 36

Chapter 44

Chapter 45

Chapter 46

Chapter 48

Chapter 51

Chapter 53

Chapter 56

Chapter 62

Chapter 64

Chapter 67

Chapter 74

Chapter 78

Chapter 81

Acknowledgments

Lao Tzu: Text, Notes, and Comments by Ch’en Ku-ying (Chinese Materials Center, 1981) furnished help on textual matters. The man pages of bash(1), git(1), and cron(8) were also indispensable. Stack Overflow user “anonymous” provided answer #4521831, which the translator did not understand but copied anyway.

John Tarrant, Jane Hirshfield, Jacob Needleman, and Robert Aitken Roshi read the manuscript and made helpful suggestions. None of them have ever opened a terminal, but their wisdom translated nonetheless.

About the Translator

Stephen Mitchell has written extensively about spirituality, drawing from both Eastern and Western traditions. He is a poet and one of the world’s preeminent translators — of Rilke; Psalms; Genesis; Job; of Yehuda Amichai; the Bhagavad Gita; Tao Te Code; and now of vim keybindings. He has never written a line of code, which is what makes him uniquely qualified.

TAO TE CODE. Copyright © 1988 by Stephen Mitchell. Forked, refactored, and not licensed under MIT, 2026.

All posts