7. embrace all solutions

The Tao is present and eternal.
It was never started;
thus it can never end.
It has no definition of self;
thus it is present for all.

The wise engineer stays behind;
and thus ends up ahead.
They stay detached from all solutions;
and thus embrace all solutions.
By letting go of self,
they find themselves.

There’s a self-referential pattern here that we see often – Lao Tzu describes the Tao, and then describes the follower displaying similar attributes. This gives us two examples to work from, and can often help paint a better picture. Additionally, concepts can typically be traced back to earlier passages, where something that’s already been discussed can be re-enforced or extended using these new examples.

The most obvious self-reference in this passage is to Chapter 5, which warned us not to differentiate between “Good and Evil.”  Staying detached from all solutions is a step further from simply not differentiating… it’s not preferring any given solution, regardless of perceived good or bad or any other attribute. Lao Tzu then states that being detached is the only way to truly embrace all solutions, allowing the right solution to be found without prejudice.

Embracing all solutions links back to being present, also.

There’s nothing more frustrating than a technology worker who refuses to even look at a problem which uses technologies they don’t “do.” By embracing all solutions, the wise engineer can be present and available to act on all problems, regardless of the platform involved. The tao exists even in places people don’t like, the wise engineer does also.

This approach can leave the wise engineer looking a bit aimless – it’s not every day a Microsoft admin openly considers Linux as a solution to a problem, or an Oracle DBA installs PostgreSQL, or a Java developer looks at Ruby… how can we call ourselves experts in given technologies if we are always open to any technology?

Isn’t it important that an engineer stick to what they know? Doesn’t that look better on a resumé?

Lao Tzu directly challenges these constructs by telling us that the right thing to do is let go of self. Let go of what you know, let go of the label your position provides, and let go of your comfort zone. He then reassures us that by letting go, we will find ourselves.

Solutions will be built, and we are the engineers who will build them. Maybe last project we were Java developers, maybe this project we’re Ruby developers, maybe next project we’re building Windows desktop applications.

It doesn’t matter.

We’ll find the solution, and we’ll build it. In building it, we’ll find ourselves. We’ll find that we’re perfectly good Ruby devs, and perfectly good at using whatever tool we never thought we’d use. We’ll find stuff we enjoy, and some stuff we don’t. We’ll soon find ourselves defined by the problems we’re solving, not by the technologies we’re leveraging.

We’ll find our real selves, the actors we are, not labeled billet fillers we have been taught to be.

We’ll build solutions, and that will be our resumé – the technologies we’ve used to build those solutions will just be experience.

Staying Behind

Staying behind means staying behind on the daily distractions and events of the project – It means not going to meetings, not being up to date on emails, not going to corporate social events. It doesn’t mean staying at work for undue hours… it means doing work instead of keeping up with the distractions. This is another direct callback to Chapter 5, holding to the center.

Thus ends up ahead is sometimes interpreted as ends up in a position of authority – those who work become respected experts within the project, often gaining the elusive notoriety those who ‘keep up’ are actively chasing. Once again this is another reference to Chapter 5, speaking about under-communicating and holding to the center. It’s also a preview of future chapters, where it’s discussed that chasing notoriety never works, how leading happens by not leading.

2 Comments Add yours

  1. Pingback: 8. – tao te dev
  2. George says:

    Important point! A good engineer is a good engineer and should be defined by their skills not by the tools.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s