Yes, lets reset the discussion back to article's conclusion:

"I argue that in almost any environment, you should think about how long you expect your code to last — and build it to survive that long."

I fully agree with this. And I'd also asked management this question (after explaining what their answer entails, and then still added some padding to that).

> Do you want to invest more time to understand it better and avoid more culprits? ...

> if you are working on some tiny and non-critical parts of enterprise software, you will probably stop when you know enough...

First of all, there are surely "diminishing returns" from checking whether something is good enough.

Second, "unknown unknowns" of course happen, regardless of what is being done, even in strictly regulated industries.

The problem with "good enough" is that it might be subjective. Some inexperienced programmer can consider that code, copy-pasted from StackOverflow and compiled / run once with happy path is good enough. And then is successful startup's support is swamped with complains 3 years later due to some concurrency issues - so what?

The same actually goes with choosing 3rd party libraries. Long time ago we added some kind of simple blog library to CMS we developed , and then fixed it many times - so in total it would be faster to rewrite the piece with more quality...

And yes companies go bankrupt if they "overdo" things ( ~over-engineer). That is why it is cost-effective for startups to always hire A-players ( ~ https://apple.fandom.com/wiki/A-players ) - those have better sense of "good enough", and can achieve longer horizon with the same efforts. While "C-players" tweak "tiny and non-critical parts" later on.

Still, it's all very speculative: who and how can being something objective into defining what is good enough for this piece of code, even knowing the expected life-span?

My current answer to that would be that foundations (platforms, frameworks, libraries, and such) should be built by experienced guys. This then shifts the question whether you need anything foundational? This is hard to answer, but even if one, lets say, data scientist, writes only one-time scripts for years, I believe there is still something, which can be factored out of that and make the work faster. Foundational (old name for it - system) software is the form of knowledge one already learned. Experienced guys understand that and keep structured track of records of what they do.

That is why bookshelves were invented thousands of years ago. Why pile of books on the floor is not good enough?

To answer your question what that gut feeling really is?

Part of the experience does not depend on SomeNewTech - it can be applied to anything. Developing working habits to accommodate AnyTech faster is something, which should not be forgotten in any kinds of rush.

Certain discipline (like keeping a log / notes / journal, always organizing your job, reflecting from time to time, etc) and knowledge patterns can be applied always.