Why I Make the Operation Log Public

In Chapter 1 I touched briefly on the project stance of "making the operation log public." Here I want to go into that a bit more. The question is: why make it public at all?

I Used to Think Logs Were Something You Kept Hidden

To be upfront about it: I started out believing that the inner workings of an implementation were things you kept to yourself. The trial and error, the failures, the bad calls. I honestly did not see much value in sharing any of it.

"Wait until it works, then publish." "Nobody benefits from watching someone fail in real time." That was my thinking.

In particular, publishing my own failure logs for this project was something I could barely imagine. I realize now that I had an unconscious equation in my head: failure equals embarrassing. I assumed the normal way to run a blog or write technical documentation was to line up the finished results, polished and clean, and show only those.

Something Unexpected Happened When I Started Publishing

The turning point was a moment when I decided, "Let me just try putting it out there." There was no particular reason behind it, and nobody gave me the push. My motivation was entirely passive: keeping things hidden was starting to feel more trouble than it was worth.

I wrote up the implementation log, included the story of what went wrong, and put it out. What happened next surprised me. Writing took more time — yet my decisions got faster.

The reason is straightforward. Writing forces you to sort out your thinking. When you try to put into words "why did I make this choice," the vague parts inside your head come into the light. Sometimes you realize a decision had a weaker basis than you thought. Sometimes you remember you made exactly the same mistake before.

Writing for a public audience makes this effect even stronger. When you are explaining something to someone else, you push yourself to make the reasoning actually hold together. And that process ends up organizing my own thinking. That is what was happening.

The Effect of Having "Another Set of Eyes"

The second thing I noticed was that the state of being published — simply having the log out there — had its own effect.

This is not about getting comments from readers, or a post going viral on social media. I am talking about something different: the condition of "someone might read this" acts as a quality check on its own.

For example, when I am about to write down a decision I made carelessly, I often pause mid-sentence. "Would this hold up if someone read it?" That pause makes me think it through one more time. Sometimes the decision itself improves. Sometimes I just add a sentence of explanation. Either way: simply assuming something is public makes me more careful, without consciously trying to be.

This same dynamic shows up in AI-assisted development too. The approach I call separation of powers (here meaning: dividing execution, review, and final approval among separate agents so no single agent can complete a task without oversight) — which I will go into in detail in a later chapter — is built on the same intuition. "Structurally introducing another set of eyes" works whether the other party is a human or an AI. That is my takeaway.

That Is Why I Keep the Failure Logs Too

For all of those reasons, this project publishes not just the logs of what worked, but the failure logs as well.

Three reasons:

1. To sort out my thinking. Writing for an audience forces clarity.
2. The "other set of eyes" effect. Writing with the assumption of a reader makes me more careful without effort.
3. To be useful to anyone trying something similar. Failure logs have higher reproducibility — and when you are stuck on a problem, you are far more likely to be searching for how someone dealt with a failure than for a success story.

On that third point: technical articles tend to document only the path that worked. But when you actually try to build something, the failures you run into are the ones that come up again and again. They are also the ones you most want to find when you search. So I intend to preserve the full arc — failure, correction, learning — as intact as I can.

I will fail again. I am sure of it. When that happens, the bad call and the course-correction that follows will be recorded here, matter-of-factly, as part of the log. That is the intention behind the project stance of "making the operation log public."