[curyous]

What about the cost of putting shitty, slow software into the world?

How about having respect for you user's time? Depending on how many users you have, shaving seconds or milliseconds off your response time will save humanity hundreds, thousands, or millions of hours waiting for your software to do something.

[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.

[nullsense]

I happen to have it on good authority that there is an endpoint lurking somewhere in our API that has a p99 latency of almost 3 full hours per request. We clearly don't respect our users time. Or our own. Or basic software engineering practices. Sigh.

[ficklepickle]

That is amazing. It must be quite the tenacious client that doesn't timeout on that.

[nullsense]

Yeah client's will timeout for sure after a few minutes. The API doesn't know that though... it'll just sit there wasting an ungodly amount of resource and causing tonnes of noisy neighbor problems. You look in the APM traces and see one with 8 million spans that enumerates the whole database. Just silly. It's easy to be a 10x engineer in an environment where there is a lot of 0.1x engineering :(