I find the key is to always write your published code so that it's intention is clear. This doesn't require knowing what the ideal code is or an attempt to have

I find the key is to always write your published code so that it's intention is clear. This doesn't require knowing what the ideal code is or an attempt to have all the requirements pinned down, and it can result in code that is "sloppy" as in "not aligned with what we actually want," -- but we should avoid being sloppy in terms of "this is what I intend this code to do." Requirements and understanding change, and so code should change as well, and this happens with greater frequency earlier in a project. But code that clearly expresses its intention makes that much easier -- someone reading it (maybe even the original author!) can better see "does this code actually do, what it thinks it does, does it do what we need it to do". Optimizing for speed or memory footprint might or might not be premature optimization. It's not always easy to tell. But optimizing for _clarity_ is never a premature optimization.