watching the creator of The Witness do some live stream coding made me realize this too. he just typed the convenient thing he needed at each moment and didn't try to abstract away the mess. just forged ahead.
Thinking of video game, I think this is a good analogy: a lot of what you write in the beginning are just tools to your own program.
I'm really talking about the lines in your code, they're structured so well that they will help forge more code in the middle and later parts of your code life.
Like any good video game, if you produce good tools in the beginning to produce levels, modes, multi-player games, etc... then you will produce something great.
If you don't care about what you're writing, then it will become a huge mess and you will either give up or your users will give up. Or once in a life time, the mess you created will still be fun enough that everyone will start playing it, deadmau5 will make a tattoo of it and Microsoft will buy you out and you will have the most expensive house in the world/LA.
But you can go too far there. The Witness guy explained it like this: You need to do a breadth first search of your code. If you rabbit hole for weeks making the perfect level design tool before you have already made a working prototype of the game for example, you might then months later, as you build out the game, realize the level building tool you have made isn't really suitable.
As you start filling out the breadth of your design a time will come when you know an idea is going to work, and you have more knowledge to inform your tool.
Of course to what extent you should approach the coding breadth first vs depth first will depend on how clear of an idea you have for the design. If you were just doing a near-clone of Doom and you have done this before then maybe you can just rabbit hole pretty deep from the get go.
