There's basically just one golden rule: a programmer tries to minimize his total amount of work (because then s/he has more work capability available for any of the more interesting stuff).

This applies to throwaway code vs. maintainable code as well.

In programmer's head there's a running judgement ongoing while crafting something new: there are constant decisions on if cheating with quick'n'dirty hacks is the way of least effort for one part of the software or whether the total effort will be minimised by expending more effort now to do it in a more reusable way that saves effort later.

For example, some parts are just written quickly to test another part more quickly, and that another part might be contained in a module whose interfaces are really worth designing first and coding later. But some of the code inside of that could be replaced by a quick hack for now. Good things and bad things interveawe, interline, and intertwine and in the end just the right places are done perfectly and just the other right places are cobbled together just enough to keep the system together.

We occasionally do misses there, but good programmers have a pretty good hunch on which way to lean at which stage of development and which part of the code.