[mi100hael]

Your experience at Amazon probably isn't due to the incompetence of others, but due to a difference in alignment.

In the business world, the time of highly motivated, talented engineers is extremely valuable. It doesn't make sense to dedicate any more of their time than necessary for the average internal webapp. Adding automated builds/tests is usually time that's not being spent on more impactful initiatives for the business.

[mindcrime]

It's a shame that you're being downvoted, because there is a lot of merit to what you say. Business leaders do not always value technical craftsmanship and quality to the same extent that we do. And that creates situations where even competent developers are incentivized to cut corners, deliver work that they aren't necessarily proud of, etc. But as long as "the business" is funding the work, and it is "just good enough" to meet their needs, that's the way things are going to remain.

Do I like this state of affairs? Not at all. But it would be silly to ignore the plain, obvious truth.

[nuancebydefault]

Indeed. The business people often think cutting corners is not a big deal, especially to win time, while technical people who are in till their elbows simply know it is not the best strategy. But the latter should think, 'it pays the rent' .

[AmIAnElitist]

I'll take this viewpoint into consideration, thank you.

My previous philosophy was that few projects past MVP stage are deploy and done, and it's a major long run time sink to have to deal with the problems not having the basic tooling creates.

I like to think about it like this: A project looks like y = mx + b, where b is the overhead of inital setup, y is the output, x is dev time and m is the efficiency of devtime. If you skip the setup, you lower the b to 0, but with enough required y you actually end up paying more cost (and time = money since someone is cutting devs a check) than a project with more efficient dev time (lower m).

I had thought that in general testing + automation is worth it in the long run. Thanks for your input, perhaps my previously held philosophy is based on the flawed idea that all projects have some degree of maintenance required.

[noodle]

Many business, products, features, etc never survive long enough to get to "the long run".

[bluefirebrand]

Also, many businesses, products, features, etc never survive long enough to get to "the long run" specifically because people were building out automation, testing, etc.

Doing all of the best practices can mean your competitors beat you, just because they deliver "good enough" faster than you deliver perfection

It's not ideal but it's reality.

[noodle]

Yep, for sure. I've witnessed this first-hand, too, many times. Watched many startups die from this desire to build the perfect version of a thing that no one wants to buy.