Iterating by Describing the Gap
Describe the Gap, Not the Verdict
The single highest-value habit in this whole course is simple. Describe the difference between what you got and what you wanted, rather than passing judgement on it. "This is wrong" contains no information. "The list shows all bookings, but it should only show the ones for the selected date" contains everything needed. The pattern is: here is what I see, here is what I expected, here is the difference. It works for the same reason a good bug report works for a human colleague. A precise gap points at a precise change, while a complaint invites a guess. And if you find you cannot describe the gap, that is genuinely useful information too. It means you have not yet decided what you wanted.
- What I see, what I expected, the difference between them
- "Wrong" and "bad" carry no information; a gap does
- A precise gap produces a targeted change instead of a rewrite
- If you cannot name the gap, you have not decided what you wanted
Change, Do Not Restart
When something is not right, the instinct is to wipe it and describe the whole thing again from scratch. Resist it. Starting over throws away everything that was already working, and hands you a fresh set of unrelated problems. You swap known issues for unknown ones. Ask for the specific change instead: keep everything else, change this one thing. Restarting is occasionally correct — when the whole approach was misunderstood, or when the code has become a tangle nobody can follow. But it should be a deliberate decision you can justify, not a reflex triggered by frustration. If you do restart, take the lesson with you. Write it into the spec first, or you will arrive at the same place.
- Ask for a change, not a rewrite: "keep the rest, change only this"
- Starting over trades known problems for unknown ones
- Restart deliberately, for a stated reason, not out of frustration
- If you restart, update the spec first so you do not repeat the misunderstanding
Know When to Stop
Iteration has diminishing returns, and a point where it turns negative. If three or four rounds have not fixed something, more rounds will not either. Stop and change the approach instead. Perhaps the request is unclear. Perhaps you are asking for something the tool is not suited to. Perhaps two of your requirements quietly contradict each other. Equally, know when to stop because it is good enough. Prototypes do not need to be finished; they need to answer their question. The habit of endless small improvements feels productive. It is also one of the most reliable ways to never show anyone anything, which defeats the reason you built quickly in the first place.
- Three or four failed rounds means change the approach, not the wording
- Repeated failure often means two requirements contradict each other
- A prototype is done when it answers its question, not when it is perfect
- Endless polish feels productive and prevents you showing anyone anything
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.