I'm really glad to see someone discussing the actual mechanics of how they program. We need more arguing about which mechanics are the best and less arguing about which tools are the best. I'm sure the top 1% of programmers are the top 1% because of their awesome mechanics, not their awesome tools.
In my experience the quality of your debugging facilities determines a lot of how important it is to program by accretion. If you are getting really high quality tracebacks when there is a bug, it tends to be safer to add a lot of code at a time.
For me the Holy Grail has always been for my program to run on the first go without any bugs. I have achieved this for small Python scripts. To write conceptually correct code on the first go requires a much higher level of mental engagement, but it is far more satisfying than working by trial and error. (I guess it is probably all right to have trivial bugs like a forgotten import statement or a misfired library call.)
In my experience the quality of your debugging facilities determines a lot of how important it is to program by accretion. If you are getting really high quality tracebacks when there is a bug, it tends to be safer to add a lot of code at a time.
For me the Holy Grail has always been for my program to run on the first go without any bugs. I have achieved this for small Python scripts. To write conceptually correct code on the first go requires a much higher level of mental engagement, but it is far more satisfying than working by trial and error. (I guess it is probably all right to have trivial bugs like a forgotten import statement or a misfired library call.)