In my team, if something needs redoing, we usually make that decision immediately after shipping the "get it done" version, so everything's still fresh in our m

In my team, if something needs redoing, we usually make that decision immediately after shipping the "get it done" version, so everything's still fresh in our mind. Other times we review things once a problem comes up, like code is becoming too difficult to maintain or is performing poorly. To us, code quality matters insofar as it affects us, whether that's performance (rarely a problem), maintenance (often a problem in our older code), or something else. I think this is a good compromise. Don't burn mental cycles optimizing (whether that's for readability, CPU, memory, whatever) until you have to, but really take time to do it when you have to. Of course, write the best code you can in the mean time to minimize the need to rework old code.