I love optimizing stuff. But if customers don't care about the code being faster, my optimization isn't valuable to them. One thing I can do is work in an area where speed is important at the moment (I say "at the moment", because it changes over time, as people work at it, and there's always Moore's Law, there can also be standard library and VM improvements). Example:
John Carmack's genius for graphics optimization was highly valuable for Doom, because the hardware wasn't powerful enough to do graphics fast enough for people. Gradually, over time, the hardware has improved, and his talent has become less important. But recently, with his work on the iPhone, his genius again becomes crucial, to tweak out every last bit of performance. You can hear his delight that his favourite skills are important again, at 1:50: http://www.youtube.com/watch?v=keu4GiTGQ6M
On the other hand, I'm doing something very complicated at the moment (for me, anyway). To be able to reason about this, I have to separate it into modules that don't interact very much - even if that makes it slower.
Because it's not yet clear exactly what the market wants, I'll need to be able to iterate on it, doing different experiments, trial-and-error, backtracking. Therefore it needs to be written in a very simple and straightforward way (no tricks!), so that I can quickly understand and change it. This amounts to "good design" - but it's only because that's what's needed.
John Carmack's genius for graphics optimization was highly valuable for Doom, because the hardware wasn't powerful enough to do graphics fast enough for people. Gradually, over time, the hardware has improved, and his talent has become less important. But recently, with his work on the iPhone, his genius again becomes crucial, to tweak out every last bit of performance. You can hear his delight that his favourite skills are important again, at 1:50: http://www.youtube.com/watch?v=keu4GiTGQ6M
On the other hand, I'm doing something very complicated at the moment (for me, anyway). To be able to reason about this, I have to separate it into modules that don't interact very much - even if that makes it slower. Because it's not yet clear exactly what the market wants, I'll need to be able to iterate on it, doing different experiments, trial-and-error, backtracking. Therefore it needs to be written in a very simple and straightforward way (no tricks!), so that I can quickly understand and change it. This amounts to "good design" - but it's only because that's what's needed.