[TeMPOraL]

I feel for you. I'd probably be just as distracted as you were if this happened in the middle of an interview, but in the off case I weren't, I'd probably talk the interviewers' ear off. What they seem to not understand is, this kind of correction is natural and perfectly normal when you're writing code. I do it all the time - I think of a small piece of code to write, I write it, and before I'm done I notice obvious improvements, which I do on the fly.

It's not "premature optimization", as it costs me nothing (on the contrary, not doing it will cost me my focus / peace of mind), improves performance of the code - or rather, avoids stupidity - and often improves readability, as the code is now closer to a "pure" description of what it's supposed to do.

I've long held that a big part of why software today sucks so badly is because people don't do this, or likely can't do this. They write stupid code, and never bother to learn how to write non-stupid version of the same code by default.

[neilv]

I suppose it might be more normal for C and C++ programmers to get in the habit of meticulous thinking through the code as we write it, since that's more a necessity than in most other languages. (If we're not careful, we risk having to pay with painful debugging sessions, and expensive correctness/stability/security problems.)

But meticulous coding is still useful for nontrivial code in any language that we want to work well. And it's not that hard; it's just something we practice and get better at over time.

[progmetaldev]

This is the same process that I follow. I think the best developers I've met are constantly going through this iterative approach as they code, instead of leaving it to come back to. Besides not having the time once a manager sees a working model, I think this makes you a better developer and allows you to focus on the problem more clearly with a "clean" initial solution.