What I'm saying is that you shouldn't draw such general conclusions from seeing a simple algorithm work in a particular case. Your problem-game turned out to be algorithmically simple. This probably makes it more appealing as a game. But most things in life will not be as simple, and this includes large coding projects.
What you call the repair step I see as running the greedy algorithm again, from a different node in the search graph.
The conclusion I drew from this experience was that I should get over my fear of making mistakes. I could have been more clear on that in the post.
There's probably some optimal level of fear-of-mistakes for any given project. Monorail made me realize my brain was tuned too far in the fear direction. I stand by that generalization.
"It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch. Even if you have to occassionally press the “clear” button to start over."
This is what I was referring to. Yes, if you tackle coding projects that are challenging mostly by size and not by algorithmic difficulty, simply plowing ahead is the right attitude. But sometimes you will encounter real challenges, and for those you will need all the top-down design and logical tricks that you can muster. To the extent that my personal experience is relevant, for my PhD thesis I've designed and implemented a novel algorithm. I went through three non-functional versions before I realized that I actually needed to spell everything out on paper first, before writing a single line of code. After that, I was done in two weeks.
Can you define "algorithmically simple"? This looks like hamiltonian cycle with an extra constraint that there is one bounded region. I wouldn't be surprised if this problem was NP-hard.
What you call the repair step I see as running the greedy algorithm again, from a different node in the search graph.