Speed is underrated. I've worked on a lot of side projects and for a long time I couldn't get them done. I spent too long "perfecting" baseline things like folder structure (really) and overall system design. This made things slow-going and I tended to abandon them.
Over time, I started just hacking things together and shipping them, worrying less about perfecting those initial things. (I used YAGNI a lot in my decision-making.) What I learned is that there were so many more things I had to do and had to learn to do to ship. I could only get to those tasks and learn those skills by "skipping" through the earlier tasks. Working quickly helped.
I started thinking of projects as this vertical stack of work that you move up from bottom to top. If you could look holistically at absolutely everything you needed to do to ship a project, you could mark some as having a larger impact on the success of the project than others. Those are things that require more time and energy.
When you move slowly, you have a very small scope of the overall project, just stuff at the bottom, and predictions about the future. You may not really know what's ahead. If you go slowly and try to do everything perfectly down there, you spend a lot of energy on a small subset of tasks which may actually have smaller impact than something in the middle or towards the end.
Speed allows you to move through those early tasks move towards a more holistic view of the entire system so that you can determine which are high impact and which are not. You might need to double-back on an earlier task if you misjudged something as low-impact and ended up spending less time than you should on it, but at least you're not pouring energy into low-impact tasks on average.
It's not quite the same thing, but building a prototype is a good example of learning the end to end of a system without worrying too much about quality. It gives you an initial idea of what's possible and you use that to get a better picture of what's high and low impact in a project.
This is a valid approach, but not because of its "speed".
When you start a project, you have a great many things you don't know and need to learn. This is the case in 99% of projects out there. By definition, you cannot at the start of it optimize for things you don't know anything about, because... how, exactly?
If you work in a particular stack a lot, prepare a starter project template. Put some time into it, set it up so that it is optimized for letting you learn the things you don't know and helping you discover and make architectural decisions as they become necessary to make. And then just go wild.
This is the bottom-up programming approach advocated by pg in his book, IIRC. Have a setup where you can iterate quickly in the small, and make it easy to abstract and refactor as you go. You don't need a Lisp for that, just some tools with proper configs. It's also what R&D guys tend to do naturally with their Jupyter Notebooks - the difference, other than the kinds of problems faced, is that devs don't have the luxury of leaving the code in a form of REPL session transcript.
Not OP. But applies to long term support, remember the loooong overdesigned redesign? Yeah, don't do that and rather make small quick improvements. "OH you found a typo in our config format? Update it and it'll ship in the next patch". Instead of "naw it's fine, leave it we're rewriting the configuration subsystem in that fancy new yaml/json format".
Over time, I started just hacking things together and shipping them, worrying less about perfecting those initial things. (I used YAGNI a lot in my decision-making.) What I learned is that there were so many more things I had to do and had to learn to do to ship. I could only get to those tasks and learn those skills by "skipping" through the earlier tasks. Working quickly helped.
I started thinking of projects as this vertical stack of work that you move up from bottom to top. If you could look holistically at absolutely everything you needed to do to ship a project, you could mark some as having a larger impact on the success of the project than others. Those are things that require more time and energy.
When you move slowly, you have a very small scope of the overall project, just stuff at the bottom, and predictions about the future. You may not really know what's ahead. If you go slowly and try to do everything perfectly down there, you spend a lot of energy on a small subset of tasks which may actually have smaller impact than something in the middle or towards the end.
Speed allows you to move through those early tasks move towards a more holistic view of the entire system so that you can determine which are high impact and which are not. You might need to double-back on an earlier task if you misjudged something as low-impact and ended up spending less time than you should on it, but at least you're not pouring energy into low-impact tasks on average.
It's not quite the same thing, but building a prototype is a good example of learning the end to end of a system without worrying too much about quality. It gives you an initial idea of what's possible and you use that to get a better picture of what's high and low impact in a project.