Making it 'raw fast' is what compilers/JITs are for.

You still need to pick the right algorithms, but I've personally been really focusing on elegancy. Maintenance and Operation of code is the major costs of software, not writing new stuff -- so when you write new stuff, I believe that decreasing those other costs should be the first priority.

I think you mean "elegance". ;-)

That said, I agree with you. Most of the time, the elegant solution is fast or can be made fast.

I agree completely. A common mistake is thinking that performance can be tacked-on later. Thinking about performance up-front can inform elegant designs.

'git' is a good example of this.

Targeted performance improvements tend to make specific operations more efficient. Elegant architectures tend to completely eliminate huge swaths of duplicate and unnecessary operations, and so typically have the opportunity for much greater performance improvements.

I don't find that at all — I find that keeping it elegant keeps it adaptable, applicable in a broad set of circumstances, and understandable. And that these things keep a program from getting slower over time (both pre- and post-deployment) as requirements change.

I also find that a lot of times when programmers look at something elegant and say "that'll be slow", it's because they're wrongly estimating the relative speeds of things. A common example: they're counting function calls when they should be counting I/O operations that are many, many orders of magnitude slower.

I'd add "make it work right" as the second entry :)