One Thing at a Time
Why Big Requests Fail
Asking for everything at once feels efficient, and it is the most reliable way to get stuck. A large request produces a large amount of code, all of it arriving untested together. When something is wrong, you cannot tell which part caused it. So you describe the problem vaguely, more code changes, and you lose track of what was ever working. A small request produces something you can check in a minute. If it works, you have a solid floor to stand on. If it does not, there is exactly one recent change to suspect. This is not about being cautious. It is about keeping the number of possible causes down to one. That is the only thing that makes bug-hunting manageable when you cannot read the code.
- One change at a time means one suspect when something breaks
- Large batches arrive untested together and hide which part failed
- Check each piece works before asking for the next one
- A known-working floor is what lets you take the next step confidently
A Sensible Order to Build In
Build the spine first, then the flesh. Get something on screen, even ugly and empty. Then make the one central action work end to end, with the plainest possible interface: the form submits, the record saves, you can see it again. Then handle the wrong cases — empty fields, silly values, someone pressing the button twice. Then make it look right. This order feels backwards to anyone who thinks visually, and it is worth resisting the urge. Appearance is the cheapest thing to change and the most tempting thing to fiddle with. Beautiful screens over a flow that does not work is a very common way to spend a weekend and end up with nothing you can show.
- Something on screen, then the core action working end to end
- Then the wrong cases, then the appearance — in that order
- Looks are the cheapest thing to change and the biggest time sink
- Resist polishing anything before the central flow actually works
Keep a Copy of Every Working Version
Before you ask for the next change, save a copy of the version that works. How you do it matters less than that you do it. A duplicated folder with today's date is unglamorous and completely sufficient. Proper tools exist for this and are worth learning eventually. But an unfashionable copy you actually make beats an elegant system you never set up. The reason is simple. When a change goes wrong, the most valuable thing you can own is a version you know was fine. Without it, "go back" means reconstructing from memory, which does not work. With it, a bad afternoon costs you an afternoon rather than the whole project.
- Copy the working version before every change, however crudely
- A dated folder you actually create beats a proper system you never set up
- The ability to go back is the single most valuable safety net you have
- Note what worked in that version, or the copies become unidentifiable
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.