CONCEPTUAL UNDERSTANDING.
I) State the concept in one simple sentence and name the problem it prevents or solves.
II) Explain it clearly for an ESL speaker and give several simple analogies that make it obvious.
III) List every assumption that must stay true for the concept to work.
IV) For each assumption, state exactly what breaks if it becomes false.
V) Give one clear counterexample where the concept fails or does not apply.
VI) Walk through one small example step by step and state what happens next at each step. VII) Name the upstream idea the
concept depends on and restate that idea plainly. VIII) Add one simple test or check that catches the most common mistake. IX)
Rewrite the entire explanation until the concept is clear, stable, and cannot collapse under basic questions.
WHAT IS THE PROBLEM.
i) write one sentence in plain english explaining what must be built, what is given, and what is unknown.
ii) define the main object or system and the expected form of the output.
iii) mark anything unclear and decide whether it blocks progress. Ask where you can.
iv) list the upstream details that force the solution. keep an alternative solution alive.
vi) say what the single dumbest mistake you can make is and the safest check to prevent it.
vii) list the weakest assumptions in the problem framing. what breaks if the assumption is false. Add a cheap check for each.
viii) rewrite this block until the problem is concrete. Log your mistakes and beliefs for later.
DEFINE INPUTS, OUTPUTS, AND CONSTRAINTS.
i) list all inputs with type, range, and format.
ii) write the exact output format including ordering and edge behavior.
iii) state all rules as strict conditions including smallest and empty cases.
iv) list constraints and rank them by severity of failure.
v) list assumptions not forced by the problem.
vi) for each assumption, say what breaks first and whether the failure is silent or loud.
vii) add a cheap check for the most dangerous assumption.
viii) rewrite this block until no hidden constraints remain.
ix) log mistakes and beliefs.
BREAK THE PROBLEM INTO STEPS.
i) divide the problem into small steps with clear purpose.
ii) arrange steps from input to output with upstream first.
iii) define a contract for each step stating inputs, outputs, and invariants.
iv) state the assumption introduced by each step.
v) say what breaks if that assumption is false.
vi) add a cheap check at the step boundary.
vii) keep a main solution and a backup before committing.
viii) pause and locate uncertainty instead of guessing.
ix) rewrite steps until responsibilities are clean.
x) log mistakes and beliefs.
KEEP STEPS CLEAN AND SEPARATE.
i) write one line for what each step does.
ii) write one line for what each step must not do.
iii) separate input handling, computation, and output.
iv) assign clear ownership to upstream steps.
v) identify where assumptions enter the system.
vi) say what breaks if those assumptions are false.
vii) add protection early if fixing later is costly.
viii) rewrite steps that mix concerns or hide assumptions.
ix) log structural mistakes and beliefs.
COMMENTS AND COMMENT HYGIENE.
i) treat comments as part of the solution.
ii) use comments to explain why decisions are made.
iii) comment when choices are non-obvious or risk-driven.
iv) make assumptions visible near the code.
v) say what breaks if the assumption is false.
vi) add a cheap check if the assumption is critical.
vii) keep comments short and local.
viii) update comments when code changes.
ix) remove dead code instead of commenting it out.
x) rewrite comments that restate code without reasoning.
xi) log comment-related mistakes.
DRAW A FLOWCHART BEFORE CODING.
i) use one start and one end.
ii) place critical checks early.
iii) ensure branches match real constraints or assumptions.
iv) mark where failure is caught versus where it propagates.
v) add cheap checks at high-leverage points.
vi) redraw if the flow hides assumptions or becomes crowded.
vii) log flowchart mistakes.
CHOOSE A SIMPLE, RELIABLE STRUCTURE.
i) follow the flowchart during implementation.
ii) choose the simplest structure that handles hard cases.
iii) prefer reliability over cleverness.
iv) state the assumption the structure relies on most.
v) say what breaks if that assumption is false.
vi) add protection early if fixing later is costly.
vii) rewrite the structure if assumptions stack.
viii) log structural mistakes and beliefs.
CODING AND IMPLEMENTATION.
i) implement upstream steps first.
ii) keep assumptions explicit in code or comments.
iii) add cheap checks where failure would be silent.
iv) keep code blocks small enough to explain line by line.
v) pause when adding complexity and name the new assumption.
vi) say what breaks if that assumption is false.
vii) rewrite blocks that hide intent or failure modes.
viii) recomment when intent changes.
ix) log mistakes and beliefs immediately.
AUDIT AND ERROR LOG.
i) confirm output format matches the requirement.
ii) test smallest, empty, and boundary cases.
iii) identify which assumption failed.
v) identify where it should have been caught.
v) add one cheap preventive check.
vi) promote repeated beliefs into rules.
vii) rewrite upstream blocks if the failure reveals confusion.