For years I’ve been in the camp that optimization of software should come towards the end of a project. Build the software, profile it, then fix any outlandish problems. And that has largely worked fine. I tend to write the code for projects in which maintainability and simplicity outweigh performance. Part of my reasoning, too, has been because it’s often hard to tell where the performance problems lie until you take a measurement.
And that’s largely still true. But I’ve gradually come to push more in the direction of writing efficient code first. There are a lot of ways to do this, and once they become second nature, the effect it has on your ability to deliver should be minimal, while at the same time, your code will be, even if just a small amount, more efficient than it otherwise would.
Some of these methods include taking iteration-independent calculations outside of loops, choosing the smallest possible data type, filtering lists as early as possible (in the database if you can), reducing the amount of data delivered by web services, designing web services to be more coarse-grained instead of fine-grained, caching database access of things that will be accessed frequently, and perhaps even using fewer mutable objects. I’m sure you can think of many more. Some of these things a smart compiler will probably do for you, but they are good habits to be in nonetheless, particularly if you happen to not be using a smart compiler, or don’t know exactly how much optimization your compiler does.
All of this said, you can’t escape the profiling if you are experiencing performance problems. If nothing else, it will teach you about how to help avoid similar problems in the future.