I had an interesting conversation with a coworker several months ago. We were discussing the malleability of programming, and the pros and cons of being able to change pretty much anything at anytime on a whim. Toss in the added security of a version control system like GitHub, and you can try nearly anything you want without consequence.
Flexibility vs Prudence
On the one hand, you can develop software with impunity. If a design doesn't work, just delete it and POOF! it's gone. No waste in materials. No running to the store again for fresh supplies. Cleanup is the "delete" key. That's great when you're trying to learn something new, or to approach a problem from several different angles to decide how to proceed.
On the other hand, there's a temptation to not bother with upfront design when it matters. Just let it evolve over time, creating the path as you go (emergent design taken to an extreme). Why bother measuring when you can simply trim existing material and conjure more as easily as thinking about it? When the "lumberyard" is simply your mind, and you can just grab a cup of coffee and start hacking away again?
"In carpentry you measure twice and cut once. In software development you never measure and make cuts until you run out of time." - Adam Morse
— Programming Wisdom (@CodeWisdom) January 9, 2018
Consequences
There are no consequences to not thinking ahead - or are there? Programming is a mental exercise, but we can sometimes slip into the mindset that the lack of a physical product means nothing physical is required in the process - I have.
The brain gets exhausted like any other organ, is only capable of doing so much in a day, and of holding so much at once while trying to figure out a problem. Using it burns calories, causes fatigue.
Spin too many cycles on a problem, stare at the same bug for a long time, and you feel it. There's still nothing visible... other than maybe you nodding off at your desk or tossing your laptop out the window.
Spin out of control without setting boundaries, and you'll stay on a problem forever. I've seen developers stretch a two-day refactor into two months - producing a piece of furniture, then burning it to the ground to rebuild a slightly different piece of furniture, ad infinitum. Even worse, I've seen developers who insisted on rebuilding major portions of a project, on a near weekly basis for almost a year (thank you JavaScript).
And in both cases, it exhausted and frustrated the entire team, as well as the devs themselves - and what we ended up with wasn't better than what we started with.
A penny now, or a pound later
And just try to revisit your own work, six months from now, if you haven't given some consideration to upfront design. It might as well have been written by someone else. You'll hate yourself.
Sometimes, hacking away at a problem is perfectly okay. But expect that sometimes, especially on larger or more indepth projects, you might be doing the mental equivalent of building a skyscraper. While deleting your work and starting over may be possible, it may be as unlikely as leveling a building just to start over with new materials and a different approach.