On the contrary, in my experience it's much more important to "play" with a concept and see it working. Too many engineers think they're going to architect a perfect solution without ever getting code on the page.
A slapdash prototype is worth the weight of 100 tests and arch diagrams.
Note: I'm not saying the latter is not important. My comment is, it's ok (and encouraged) to do potentially throwaway work to understand the domain better.
They sure do in my experience.
> On the contrary, in my experience it's much more important to "play" with a concept and see it working...
I agree with all that. That's the point: figure out what you're trying to do before building it. Of course you will not know everything up-front, and of course you would try things out to learn and progress, and, for anything that it's tiny, of course it makes sense to do this iteratively, working from the most pressing/important/risky points earlier.
Or, at least, it seems obvious to me.
In my anecdotal case: I behave like the former in some cases (crafting) and the latter in others (travel planning)
I wouldn't say one way is always better than the other.
https://pages.cs.wisc.edu/~remzi/Naur.pdf
The act of programming is building the theory of what the program does, so that you acquire new knowledge of doing things. It's not just text production.
>"[...] not any particular knowledge of facts, but the ability to do certain things, such as to make and appreciate jokes, to talk grammatically, or to fish."
Which is why re-building a program from scratch is so tempting: you've figured out the theory as you went along, now you can build the real thing.
(I've certainly seen it done though, with predicable result.)