When programming, there are 4 states that I take my code through. These states and the steps taken to get between them can be summarised in this diagram:
( Start ) | | implement V ( Works ) | | refactor V ( Nice ) | | optimise V ( Fast Enough )
When you start out, your code doesn't work. Either it doesn't exist yet or you're tasked with fixing something broken. You're aiming to reach the next state, which is Works. The only concern at this stage is to get the code working in the simplest, most straightforward way possible. Anything else is over-complicating things at this stage.
Once the code is working, you should immediately refactor it to make it more readable, maintainable, elegant, cleaner. The next stage you're heading for is Nice. Your only concern at this stage is with tidying up without changing the working state of the code. You're aiming to make the code conceptually simpler so that when someone (including you) comes back to read it in a month's time, they're not left scratching their head. You're striving to employ best practices to keep the code consistent with the surrounding project.
Finally, once the code is tidied up, you can turn your thoughts to performance. The goal you're aiming for now is Fast Enough. Note the enough part. If the code already performs within acceptable time, memory and load constraints, then there is nothing further to be done at this stage. It's vitally important that optimisation is only performed if it is strictly necessary. Changes made at this stage will undoubtedly undo the work that went into making the code Nice and should therefore be avoided without a good reason.
I think having these clearly defined states in mind helps to organise my thoughts while coding. By separating the different concerns into a distinct priority order, they give a clear focus for the design of the code at any point in time and help prevent obsessing over irrelevant details.