In this series I will be sharing my thoughts and reflecting on my experiences as a software engineer. I will be using verses from Stephen Mitchell’s translation of Tao Te Ching as a starting point for each post,

The first thing I latched on to in this passage was the mystery/manifestations dichotomy. Initially, it seems that Lao Tzu suggests that there is a hierarchy between these. It is better to be “free from desire”, rather than be “caught” in it. The benefit of freedom is to “realize the mystery”, rather than “see only the manifestations”.

But later, we are told that mystery and manifestations really stem from the same source. And it is the interplay of these two - the “darkness within darkness” that is the Way.

In the realm of software engineering, I understand the mystery/manifestation dichotomy as the relationship between the problem and the implementation. In that case the “desire” is the need to solve the problem in code. When we do not desire the solution, we can contemplate the problem to our heart’s content. But usually we need to actually write some code that does something.

In one extreme, you don’t want to jump into solving a problem you don’t yet understand - it’s a great way to waste a lot of time flailing or coding yourself into a corner. I’ve met many novice programmers who take on massive projects because they don’t understand just how complex their project is. I can say from experience that this leads to a lot of frustration and insecurity.

In my professional life, I’ve had to learn to be less gung-ho about jumping into implementations. I’ve wasted a lot of time building complex architecture for solutions that ended up being dead-ends from a UX perspective - something we could have learned by building a quick prototype and faking most complexity away.

On the opposite extreme, there is a danger in getting lost in mystery - you’ll finish making your video game after you’re done building your own physics engine; you’re going to get back to your website right after you’re done picking a frontend framework.

Trying to better understand the problem has diminishing returns - the what-ifs and the exponentially branching possibilities end up being too overwhelming. Also, I have experienced many situations in which I spent most of my planning time worrying about the wrong things. Certain issues are really difficult to anticipate, and they are revealed only when you start writing code, or build a prototype and show it to some users.

The world is full of mysteries, but sometimes you just have to buckle down and manifest something.

When in balance, understanding the problem and implementing the solution are two parts of the same process. When you’re tackling a difficult problem, you end up learning a lot as you attempt a solution. With a deeper understanding of the problem, you then improve your code, or sometimes start over with an approach informed by your new perspective.

Like Lao Tzu suggests, we may look at our earlier manifestations with disappointment. It’s popular in the software community to poke fun of startups who “don’t know how to code”, because they built unstable software in a hurry. I have, on many occasions, revisited code that I’ve written and exclaimed “what was I thinking?!”.

I think it is better to look at old code with gratitude. It got us users and paid the bills, even if it did so imperfectly. Each flaw is a hard-earned peek at the mystery, that the manifestation has revealed for us.