The Dao of just-in-time coding
Time to read
, 907 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.
樸 : the uncarved
block
The
A key concept in this text is that of
Simplicityʼs got nothing to do with it.
What
The lesson that
Thatʼs reify as in make real.
Thus the
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
But this is nothing more than a restatement of the ancient principle of
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
Remain in 樸 until the
last moment
All you Star Trek fans out there can think of
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
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.