[friendzis]

> For the vast majority of any task that requires writing code, performance is the least of your concerns;

I always have conflicting thoughts when faced with such statements. On one hand, you are right - in many cases any single code unit you write is not going to be the performance bottleneck anyway, and if it is you can optimize it later.

On the other hand, there are scaling characteristics, both algorithmic and architectural. Once you chose architecture that is just bad at the scale you target, it is going to be increasingly difficult to change that.

I guess the takeaway here is that we often forget the distinction between code performance and product performance.

[xyzzy123]

Also conflicted, but I find myself happier working with "the dumbest thing that barely works" for a first release of something. To me, this is "optimal engineering under uncertainty".

Obviously, there are limits. And maybe a difference in perspective here reflects our respective typical uncertainty.

I'd rather optimise based on user feedback and with production traces than "in a vacuum".

Very often I don't even know if the feature or product is a good idea or how much / whether anyone will actually use it.

Optimisations usually come at the cost of some flexibility and this can hurt when there's a need to evolve the product in a direction I didn't expect (and for some reason that happens way more often than it seems like it should).

[imtringued]

>To me, this is "optimal engineering under uncertainty".

Information acquisition costs are the worst, aren't they? They are everywhere and they don't appear neatly on your bill.