> Most programming should be done long before a single line of code is written
I'd rephrase this to something like: Most programming should be done before 5% of the code is written. Because "no plan survives contact with the enemy". I often develop a plan, work for just a tiny bit, and realize some new constraints. It's after that point that you should construct your grand battle plan.
> # 3 “Plan to throw one away; you will, anyhow.” (Fred Brooks, “The
Mythical Man-Month”, Chapter 11)
> Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The
second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.
I've made an opposite progression from the op. I was a strong believer of upfront design, but now value iterative approach as you do.
For the first try, hack together something working, you'll learn things along the way, validate/disprove your assumptions. Iterating on this will often bring you to a good solution. Sometimes you find out that your current approach is untenable, go back to the whiteboard and figure out something different.
Its wrong in those day , exploratory coding is better for dynamic languges like python using jupyter notebook , and then do proper coding after exploratory step..
I'd rephrase this to something like: Most programming should be done before 5% of the code is written. Because "no plan survives contact with the enemy". I often develop a plan, work for just a tiny bit, and realize some new constraints. It's after that point that you should construct your grand battle plan.