Earlier quoted context omitted.
For me HN is a great reminder that done is better than perfect.
Solving a real problem with clarity and simplicity of use by knowing your target users is far more important than clean code. However, in the long run, you need good code in order to keep doing this.
In general I would like to achieve the functional goal of the present in the most expedient way possible. If cruft and technical debt from being expedient yesterday is slowing me down, it's time to refactor.
Trying to write perfect code from the start is a fool's enterprise. Often times the full requirements and constraints of a problem will not make themselves known until you're halfway done solving it, or until you're on to the next related problem. Front-loading architecture and software design work often means solving problems you don't really have, or painting yourself into a corner when it turns out the problem is not exactly what you thought it was.