You are assigned a bug fix or new feature. You think “I can knock that out in minutes”, go to you computer, open up an editor and start to work.
Always start with a baseline. “Repro” the bug, or exercise the system without the new feature. You might be surprised by what you find.
I recently was tasked to make a trivial change to a setup script, so that the names of the demo accounts it created were different. When QA tested my change they rejected it, because an unrelated bug had slipped into the code base. It was clear to me that the problem had nothing to do with my changes, but that’s a tough sell to a QA guy who knows that things used to work. Think how much simpler things would have been if I had found and reported the hidden bug before submitting my script changes.
I am not completely sold on Test Driven Development — I think it makes you commit too soon to data shape and process interaction — but it has many benefits, one being that you start work by checking the behavior of an unaltered system. Knowing where you are starting can make getting where you want to be a more pleasant trip.
It dawned on me that this admonition, “start from a known point”, is related to the advice “change one thing at a time”. Software is hard, systems are complicated, the more you can isolate the changes you are testing, the more sure and certain you can proceed.