I've worked on this part of myself alot, and I think the core idea that changed it for me is clearly articulating the problem you're solving and not over identifying yourself with your work product.
If the problem you're solving is all the libraries/sw for x are shitty / half baked, then it makes sense to take things slow, think it out, and design something robust.
If the problem you're solving is trying to validate a business idea / market idea, it might make sense to hack something shitty together to test that hypothesis.
For me, the issue has always been that I _personally_ identify myself with my code being robust / well designed, and that makes it difficult for me to put something hacky out there, but if I focus on the objective - to validate or invalidate a potential idea - it makes it clear how to prioritize my time / energy.
If the problem you're solving is all the libraries/sw for x are shitty / half baked, then it makes sense to take things slow, think it out, and design something robust.
If the problem you're solving is trying to validate a business idea / market idea, it might make sense to hack something shitty together to test that hypothesis.
For me, the issue has always been that I _personally_ identify myself with my code being robust / well designed, and that makes it difficult for me to put something hacky out there, but if I focus on the objective - to validate or invalidate a potential idea - it makes it clear how to prioritize my time / energy.