First-Principles Thinking — Best Practise¶

How to make deconstruct-then-reconstruct a habit, not a special occasion.

The core techniques¶

Five Whys — ask "why" about a rule or decision, then ask "why" again about that answer, until you hit a fact you can check or admit it's just precedent. Small, fast, works on almost anything.
Socratic Questioning — a slower, more disciplined version for decisions that matter more:
Clarify your thinking — why do I think this, exactly?
Challenge the assumption — how do I actually know this is true?
Look for evidence — what would back this up, or contradict it?
Consider alternative perspectives — what would someone who disagrees say?
Examine consequences — what happens if I'm wrong?
Question the original question — was I even asking the right thing?
Decompose before you analyze anything else. Write the parts down first, time-boxed to about 10 minutes for a task-sized problem — don't let deconstruction start as a mental blur.
Wait for the third occurrence before calling it a pattern. Two is still a coincidence.
Diverge before you recombine. Generate at least two or three structurally different ways the truths could go back together before judging any of them — Osborn's premise (quantity breeds quality) applies to recombination the same way it applies to brainstorming: a bigger pool of candidates raises the odds a genuinely better one is in it.
Reach for a lateral technique only once the recombination stalls. Edward de Bono's random entry (force a connection to something unrelated) and provocation (state an extreme version of the goal, then walk it back) exist to break a fixed pattern — use them once the obvious recombination stops producing anything new, not as a first move.
Profile or measure before touching the rebuilt solution's performance. Make it a rule with no exceptions until it's automatic.

Daily practice¶

Pick one small rule per week and Five-Whys it. A pricing assumption, a "we've always used X for this," a limit nobody remembers setting. Trace it to a fact or admit it's precedent.
Before every non-trivial task, decompose it into parts before reasoning about the rest. Treat this as the first step of deconstruction, not an optional warm-up.
Before copying an existing solution, name the function it serves in one sentence — without mentioning its current shape. If you can't, you're about to copy form, not solve function.
Before calling reconstruction done, ask "is each part here checkable on its own?" — not just "does the whole thing work end to end?"
Before committing to a recombination, write down at least one alternative and score both against the actual goal — effort, risk, impact — instead of shipping the first one that came to mind.
Before a group reconstruction session, ask people to write candidate recombinations individually and silently before discussing. The single highest-leverage move against a room anchoring on whoever spoke first.
When something "can't be done," ask what specifically would have to be true for that to hold — and whether it still does.

Build the habit¶

Keep a deconstruction log. For a month, write down: the parts, the pattern, the truths you found, and what you rebuilt from them. Review monthly — how many entries actually reached reconstruction and a working algorithm, versus stopping at analysis?
Practice recognizing analogy on purpose. When you catch yourself reasoning by "that's how it's done," say so out loud — then decide deliberately whether analogy is fine here (cheap, reversible, well-precedented) or whether the stakes justify going further.
Run the snowmobile exercise on your own domain. Take two or three things you already have (tools, components, processes) with nothing obviously in common, break each into parts, and see what new thing the parts could build.
Re-derive one existing solution per month. Pick something already in place, pretend it doesn't exist, and deconstruct-then-reconstruct the problem again from scratch. Compare with what's there — does it still hold up?

Level up as stakes grow¶

Personal decision → Five Whys is usually enough, and decomposing only as far as you need to answer it.
Team convention / shared module → full Socratic Questioning, with evidence you can actually point to — and the abstraction has to survive someone else using it without asking you first.
Something others will copy from you / whole system → the rebuild has to be written down: the truths you started from, why the new version is genuinely better, and the algorithm has to keep working after the rest of the system changes shape.

Self-check before calling it done¶

Signs you're getting fluent¶

You decompose a problem before anyone asks you to.
You ask "is that actually true, or just how it's always been done" before you're challenged to.
You wait for the third occurrence before reaching for an abstraction.
You generate at least two ways to recombine before you commit, even under time pressure.
You catch yourself refining the form of something before you've named its function — and stop.
You reach for a profiler or a measurement instead of a guess when something feels slow or expensive.
You know when analogy is the right tool and don't rebuild the wheel(barrow) out of habit.
People can trace your reasoning from the raw facts to the new solution without you filling in gaps live.