Should you think of it? Absolutely. Should you do it? Now that's a hard question.
If you are an experienced developer, you will pretty much always have two solutions in your head: a quick and dirty, and a slow but clean. Most of the time you will yearn to use the latter, but have time only for the former.
At my company I do exactly this. Between last November and this May I wrote a lot of quick and dirty code. I was aware of such solutions (at least most of them) at the time of writing, so I added a small TODO comment to each of them. At the end of May most of our partners went on a long vacation. Business became slow, so after finishing some features I took one of my favourite scripts from my library called fixmes-by-age, collected all the TODO comments from the code base, and started to get rid of them one by one ordered by impact.
This is called a technical debt in my book (and all over the Interwebz). It's a luxury only programmers can allow themselves: imagine an architect not adding windows and doors to a house, just big holes because "we can optimise it next year by adding some wood and glass", or a doctor not closing a cut because "we can add those stitches later if the patient is OK".
Of course, you should avoid such situations to your best knowledge. For example, never ever write code that has obvious errors. Your code should always work, be it dirty or not. You can optimise for performance and edge cases later.