[KronisLV]

> I'd argue to write the "stupid" code to get started, get that momentum going.

Yes and no, depending on how dependent you become on that first iteration, you might drown an entire project or startup in technical debt.

You should only ever just jump in if:

A) it's a one off for some quick results or a demo or whatever

B) it's easy enough to throw away and nobody will try to ship it and make you maintain it

That said, having so much friction and analysis paralysis that you never ship is also no good.

[yxhuvud]

or C): You cultivate a culture of continuous rewrite to match updated requirements and understandings as you code. So, so many people have never learned that, but once you do reach that state, it is very liberating as there will be no more sacred ducks.

That said, it takes quite a bit of practice to become good enough at refactoring to actually practice that.

[amatecha]

Yeah, I think it's actually a great skill to be comfortable with not getting attached to your code, and being open to refactoring/rearchitecting -- in fact, if you have this as a common expectation, you may get really good at writing easily-maintainable code. I have started putting less and less "clever optimizations" into my code, instead opting for ease of maintainability, and onboarding for new team members to join up and start contributing. Depends on the size of project/team (and the priorities therein), but it helps me later too when I have to change functionality in something I wrote anywhere from 6-48 months ago :)