It's interesting you ask about optimization because I've been meaning to write a little bit about that on the blog. Premature optimization is definitely the root of all evil. My philosophy is that you never even think about performance until the program is functioning, and the code is well written and easy to understand. Then if your program needs a performance boost, you profile to identify the hotspots and only optimize those as necessary. There's no point in optimizing the CPU performance of a program that is IO bound anyway. Or optimizing the performance of a piece of code that only takes up 1% of the program's time, because even if you optimize it down to 0 ms, you'll still only make your program 1% faster! The exception to this rule is special cases when your program needs to be designed for performance up front. In that case you have to think about it before you write the first line of code, because there are limits to how much you can optimize a bad design later on. But that's rare. When in doubt, save optimizations for last.

Unfortunately, these days I get to do less and less hard core programming where all of this interesting stuff is even a consideration. Programming has changed a lot since I started. It used to be that you would start from a well defined toolset (e.g., the compiler toolkit, libc), and then spend most of your time building up your program from those basics. These days I find myself spending ever larger amounts of time finding the right off the shelf components and figuring out how to glue them together. When it works, this realized ideal of code reuse can be highly productive. But it's a shift from "real" engineering into more of an integration role, and it's a shift I often find unsatisfying.