[avaer]

> The engineer who pauses to deeply understand what they built falls behind in velocity metrics.

This is the most insidious part. It's not even that bad code gets deployed. That can be fixed and hopefully (by definition) the market weeds that out.

The problem is that the market doesn't seem to operate like that, and instead the engineer who cares loses their job because they're not hitting the metrics.

[xeromal]

Of course, there are counter examples but there's a disconnect between the production of something and the selling of it with almost opposing goals. Given unlimited money and time, many engineers, arts, etc will write and rewrite something to perfection. Constraints are needed because the world doesn't operate in a vacuum and unless we all live in a utopia, we have to compete for customers and resources.

Constraints often result in better results. Think of Duke Nukem Forever and how long it took them to release a nothingburger.

I just watched a show called the Knight of the Seven Kingdoms and the showerunners were given a limited budget compared to their cousin shows and it resulted in a better product.

Sometimes those metrics keep things on the rails

[bojan]

> Given unlimited money and time, many engineers, arts, etc will write and rewrite something to perfection

This is a common trope, but in my experience many engineers I met know that's not how a business runs. Dealing with the constraints and weighing them out is one of the essential skills of any engineer. Knowing when a product is just good enough is one of the things that make you senior.

[skydhash]

The usual person that believe in the trope is the one that wants something with short-term budget, but with long-term quality. Lot of engineers know the triangle of budget-scope-time. But a lot of managers want to have the cake and eat it too. When they ask to reduce time and the budget and the engineer ask what to reduce in the scope, they get all vague and shifty.