Essays about code. Essays about connection. Essays about context. Critiques.
by Charles Munat

The Dao of just-in-time coding

The uncarved block … of code.

Time to read

, 915 words, 4th grade

For more than three decades, I have taught using a just-in-time approach to learning. But when coding, I loved to over-engineer and anticipate.

Then a decade or so ago Guillermo Rauch admonished me: never write a line of code until you have to.

Doh! I have practiced just-in-time coding since. I also teach just-in-time coding … just in time, naturally.

But then I was discussing Heidegger and mental models with the inestimable Col Perks. It occurred to me that the just-in-time approach has existed for at least twenty-five centuries.

On some subconscious level, Iʼve known this all along. But it wasnʼt until recently that I made the connection.

Pʼu: the uncarved block

The 道德經Dao De Jing is an ancient Chinese philosophical text.

A key concept in this text is that of Pʼu: the unhewn wood or uncarved/uncut block. This is sometimes mistranslated as “simplicity”.

The uncarved block is pure potential
You can do many things with an uncarved block of wood.

Simplicityʼs got nothing to do with it.

What Pʼu signifies is potential. It is a simple idea: objects exist as potential until we reify them into concrete objects.

The lesson that Pʼu bestows upon us is simple. Once we reify potential into a concrete object, there is no going back. Once the uncarved, unhewn block of wood becomes a bowl or a spoon or a bust of Elon Musk, itʼs all over. The die is cast. There is no way back to our uncarved block.

Thatʼs reify as in make real.

Thus the 道德經Dao De Jing prompts us to remain an uncarved block : to remain potential. And to do so for as long as possible. In short, we should avoid reifying ourselves until the last moment.

This is, now that I juxtapose the two, the true meaning of just-in-time coding: avoid premature reification of idea into code. Guille got it right: never write a line of code until you have to.

Before we write code, it remains potential. We can pivot instantly to a very different object or outcome.

But after we have written the code, we have reified that potential into code. Code that represents significant time, effort, and money. Now, not so easy to change, is it?

Not that we canʼt change our code. We can and often do. But what if we decide after the fact that we chose the wrong path? Then we are often better off discarding our code — and our effort — and starting over.

Is it me, or does that seem wasteful?

You arenʼt going to need it

We coders — who love acronyms — have rejiggered Pʼu to YAGNI: You arenʼt gonna need it. Mmm …tomāto, tomäto.

But this is nothing more than a restatement of the ancient principle of Pʼu. The ostensible benefit of YAGNI is that we made it up. You know: the new cool.

Ha ha! Why give credit to the ancient Chinese when we can keep it for ourselves? I say poo to that.

In keeping with the current zeitgeist, YAGNI is often used in a sarcastic or snarky manner. But there is nothing snarky about Pʼu, and the ancient Chinese donʼt give a hoot about snark. Actually, the ancient Chinese are all dead. Fun fact.

Remain in Pʼu until the last moment

All you Star Trek fans out there can think of Pʼu this way: remain cloaked as long as possible. Then de-cloak only to fire ze missiles.

My partner is a business analyst (and no Trekker). She often talks about the problem space vs. the solution space. She complains that many people in the tech industry are in an awful hurry to leap to the solution space.

Sigh. More premature reification.

Ditto for developers who get tired of pondering after a few feeble efforts. Straight to writing the code they jump.

And I realized that it is Pʼu all over again. The “problem space” is Pʼu. It is the space in which we preserve potential. Any solution remains possible.

The “solution space” is the space post-reification. The deed is done. Going back is expensive.

Once you investigate this concept, the ramifications of Sr. Rauchʼs statement will blow your mind. The benefits of delayed reification are multitudinous. And they affect everything.

The “solution space” is where the reification happens. There we make concrete the infinite possibilities of Potential into a single Actual. This is how you end up with that wooden bust of Elon Musk. Urk. A balaclava, perhaps?

In physics, they call this the collapse of the wave function. Reification! From a world of varied probabilities to a single answer with probability one. Everything else is now probability zero. And this was before Heisenberg started dealing blue meth and knocking on doors.

My partnerʼs frustration is the same as mine (and Guillermoʼs): why on Earth are we rushing to solutions before we have to? Why this insane rush to prematurely reify potential?

Be the uncarved block, the unhewn wood. Stick to potential until you must embrace the actual. Code and learn just-in-time. More often than not, you will find that you didnʼt need it after all.

Thus you will avoid a lot of wasted effort.

More often than you might think, you arenʼt going to need it.

Essays about code. Essays about connection. Essays about context. Critiques.
Get notified of site updates
Button bar

Carbon emissions for this page

Cleaner than 99% of pages tested
0.01g of CO2/view Website Carbon
0.011g → 0.004g Beacon: A+
QR Code

Scan this code to open this page on another device.