[Scotrix]

It depends on the product and the user/customer impact, if it doesn’t matter that it takes 200ms or 300ms why do you care? Also, if it matters and you can scale horizontally to improve performance do that first instead of spending valuable developers hours.

[ZephyrBlu]

I think it's difference in the hacker/product mindset and the engineer mindset.

For hackers or product focused devs, making something work is the most important aspect whereas for engineering focused devs, it hurts to see such large inefficiencies that are solvable.

I empathize with the engineer mindset, but definitely align more with the hacker/product mindset.

[adrianN]

After your first sentence I thought you'd continue like this:

For a hacker, making something fast and cool is the most important aspect, whereas for engineers making careful tradeoffs between effort and customer impact are the main focus.

[ZephyrBlu]

I think you could swap 'hacker' and 'engineer' in your sentence and it would still make sense.

I'm not saying, "engineer bad, hacker good", just that we tend to value "good" code, architecture, performance, etc highly and sometimes that is to our detriment.

[saagarjha]

Operative word “careful”

[BoorishBears]

I feel the latter is just not being able to see the big picture.

People in the latter mindset don't get that providing real value to users is what matters.

Literally everything boils down to it. Even the example of making a faster application, it's literally only useful in that it increases how quickly you generate user value.

At some point once you generate enough value for your end user, the utility will outweigh a given latency problem.

Even making your server costs cheaper with optimization really matters because you can transform the savings into user value that exceeds the cost of optimizing.

So it really doesn't make sense to thumb your nose down at people who are "just sticking stuff they don't understand together" in a vaccum like they tend to do.

You don't know their runway.

You don't know how concrete their business case is.

You don't know their development budget.

The moment you're making a dichotomy between yourself and "those programmers who just put shiny legos they don't understand together", you're demonstrating a lack of understanding of the bigger picture that development fits in.

Because sometimes hiring someone who has little experience outside clicking those legos together is all that allows an idea to exist.

tl;dr: A service that loads with 100 requests instead of 1 because the developer doesn't know better still generates more value to the end user than one that doesn't exist.

[ptx]

The even bigger picture is that we (as people, who all use various services in our daily life) end up with all these services being slow and frustrating, although they do provide value, resulting in an overall frustrating daily experience.

[BoorishBears]

Nothing about what I said is anti-making a service faster, reducing frustration is certainly valuable to a user.

But the simple fact is some of those services simply would not exist in another form.

Another way to look at it is if they could exist in a meaningfully faster form easily, competitors would pick up on that.

[saagarjha]

The non-existence of a bad service allows a better service to come into existence. All too often a market is dominated by some company that got lucky and now has no incentive to improve.