Learn by building and correcting

I understand an idea better after I have turned it into a working system, watched it fail, and written down why.

A working rule. Not an absolute.

Entry updated 26 Oct 2026

An explanation can feel complete and still fall apart in contact with a real system. Building is how I find the parts I skipped. Debugging is not a detour from the learning. It is the learning.

I want the correction on record. A mistake I do not write down becomes a story I smooth over later. A mistake I write down can change the next version.

This is not an argument that theory is useless. It is an argument that I should not trust an explanation I have never tried to make true in the world.

Influences

This one comes from my own work as an engineer and a builder, more than from a single book.

How I apply it

Prefer a small working version over a longer private plan.
When something breaks, write the cause in plain language before changing the design.
Treat a prototype as a question, not as a promise that the product is finished.

What I can actually point to

The timeline on this site is the public trace of that habit: products, research, and ideas that did not all become businesses. I have not published a catalogue of private failures beyond what those entries already say.

Where this could be wrong

Building can also be a way to avoid thinking. A prototype that cannot fail the idea is just activity.
Some lessons are cheaper to take from someone else's postmortem than from repeating the same accident.

What could change my mind?

A stretch of work where the building kept me busy and the written corrections never changed the next decision.