Lao Tzu: Software Engineer

Having recently been inspired by an article about Ursula K. LeGuinn on the Tao Te Ching, I did a quick re-read (or rather, skim) of the book. I was struck by how surprisingly applicable it is to the discipline of software engineering. Note: All the quotations below are taken from the Penguin Classics (1963), English edition of the Tao Te Ching. I will note page numbers. Before I begin, though, possibly the most interesting and important point of the Tao Te Ching is on the very first page of the first chapter:

The way that can be spoken of Is not the constant way; The name that can be named Is not the constant name.

As such, take any of my interpretations or advice with an appropriately-sized grain of salt.

Aesthetics and Contrast

For a long time, I've argued that one of the most important ways to become a "good" software developer is to simply develop a sense of "aesthetics" of code. Code that is "ugly" is, in my experience, generally also bad. In the second chapter (page 6), Lao Tzu says:

The whole world recognizes the beautiful as the beautiful, yet this is only the ugly; the whole world recognizes the good as the good, yet this is only the bad.

Thus Something and nothing produce each other

Lao Tzu talks a lot about concepts and things that complement each other and therefore define each other by that contrast—it's reminiscent of dialectics though obviously it predates the European popularizers of the idea. As related to programming, it's far easier to develop from scratch a sense of code that is bad, usually because we get better at writing code as we progress in our discipline and as a result we need only look at our old code to see "bad" code. The benefit of this, though, is that by recognizing why bad code is bad, you gain an insight into what constitutes "good." For example, you may find yourself noticing a lot of copy/pasted constructs, which leads to the insight that modularizing these structures through, for example, the use of functions, would be better.

The Way

There's a recurring theme in the Tao Te Ching that one should act in accordance with "the way." I've seen this described as akin to "cutting with the grain" as opposed to against it. In the second chapter (page 6), Lao Tzu says:

...[T]he sage keeps to the deed that consists in taking no action and practices the teaching that uses no words.

In the next chapter (page 7) he says:

Do that which consists in taking no action, and order will prevail.

Bruce Lee makes a similar point when he says:

Empty your mind. Be formless, shapeless, like water. Now, if you put water into a cup, it becomes the cup. If you put water it a teapot, it becomes the teapot. Now water can flow, or creep, or drip, or crash! Be water, my friend.

Lao Tzu says, in chapter 4 (page 8):

Blunt the sharpness; Untangle the knots; Soften the glare; Let your wheels move only along old ruts.

All of these get at the same idea: Adapt yourself to the situation at hand in order to act most appropriately. I often find that one of the best ways to intuit whether or not the code I am (currently) writing is good or not is whether or not it feels like I'm "fighting the problem" or not. When fighting the problem, the code feels difficult to write. This feeling often hints that the solution isn't properly suited to the problem. In some ways this is analogous to programming in the "domain", as in Eric Evans' Domain-Driven Design, but it's also touched on by Rob Pike and Brian Kernighan in The Practice of Programming when they write (on page 61), "Once the data structures are laid out, the algorithms tend to fall into place, and the coding is comparatively easy."

Developing the sense of how to work with the problem, rather than against it makes the work more pleasant, as well as more effective, at least in my experience.

On Expertise and Leadership

Possibly one of the best quotes about leadership in the Tao Te Ching is in chapter 56 (page 63) when Lao Tzu says:

One who knows does not speak; one who speaks does not know.

This has a parallel in the Dreyfus model of skill acquisition. In particular, the "Decision" model of the Novice stage through to the Competence stage is "analytic" whereas the decision model of the Proficient and Expert stages is "intuitive." Similarly, the differentiation between Proficient and Expert is that the "Awareness" model of the Proficient is "Monitoring" whereas for the Expert it is "Absorbed." Dreyfus says (PDF):

...the analytical mind, relieved of its monitoring role in producing and evaluating performance, is quieted so that the performer can become completely absorbed in his performance

This all points to expertise being the internalization of, but also transcendence beyond, rules. This has another parallel in Shuhari, incidentally. The point being, it's often difficult to properly convey expertise because it's impossible to put into words the sense or feeling of how to do something. Expertise can only be experienced, it can't, beyond a point, be explicitly taught. This, in my opinion, lends credence to the idea in Extreme Programming of doing pair-programming as it has been, at least for me, an excellent way to impart and to absorb expertise in a way that doesn't require explicitly didacticism.

Finally getting back to Lao Tzu's quote, there is also, of course, the amusing similarity between what Lao Tzu says and the old cliché: "Those who can't do, teach" or to the idea of the task-master who talks a big game but doesn't actually know how to do anything themselves. The implication to leadership is a sentiment you'll see in many books on the subject: humility is important. As Lao Tzu says:

To know yet to think that one does not know is best; Not to know yet to think that one knows will lead to difficulty.