I could not agree more. Performance is only important if it has (an potential) impact on the user experience.
Nobody cares whether it takes 0.01 or 0.0001 seconds to calculate a number or compose a string and show it on the screen after pressing a button.

In those cases maintainability is much, much more important.

>>>For some logic, yes. Not for everything. Remember also, the effort required to maintain very fast code is often 10x to 100x that of maintaining far more simple and easily understood code that is fast enough.
>>
>>I don't buy the premature optimization trope. Even the original author retracted some of his statements.
>>
>>I rather do it fast, clean and maintainable the first time. Why deliberately build it slower? Also I make every thing a separate lego block at runtime and at coding time, so a team of developers can work together.
>
>
>It's not so much to build it slower, but to make it more clear in source code.
>
>In my experience, 80% of a developer's time is spent on maintenance of existing software, and only 20% is new development. New development is easy because you're there, in the moment, all of the design considerations from whatever specs or requirements there are fresh in your mind.
>
>Three years goes by and now you're in maintenance mode on some algorithm possibly even you wrote back then, and it is often beneficial to have some more clear code to make it easier to debug, maintain, extend, refactor, etc.
>
>There's something to be said for less efficient code in places where efficiency isn't a big deal, so long as it's easier to maintain. In places where it impacts performance it can be an issue. In other places, not so much.
>
>I've always looked at things that way, and I too began with an assembly background. I used to code all of my own personal software almost exclusively in assembly back in the 90s when I was young and my mind was able to do so without issue. As I've gotten older, I look back on all that code and realize how much more productive I could've been had I used even C for more apps.
>
>In my opinion, writing code that's a little less efficient in places where it's okay to be less efficient, so long as the reason you're doing it is to be more clear for maintenance, shows signs of being a mature developer. You recognize that emphasis on speed needs to go where it needs to go, but not where it doesn't. In those places where it doesn't need to go you can use a better coding style, and that's the correct way to go.
>
>This is just my opinion, of course ... but I'm probably right. :-)