Completely agree with this. I'm working on a startup with a somewhat legacy codebase where we're not following any of these practices, and it's completely a mess.

For example, the only way to know something happened is when the public website goes down, and when that happens I have to stop what I'm doing to SSH into the server, read journald logs to try to find out what happened, and tell that to the devs. Only recently I decided to just pipe them to a public log file and let other devs do their thing with that just so I can focus on my tasks.

Higher ups just won't let us invest time on setting up proper logging because "there are other priorities".

There's also a lot of dead code, files where some lines have 20+ trailing spaces, JWT sessions with our custom invalidation tracking, a hand-made XML parser (wtf)... It's honestly a complete mess, and I don't expect this startup to survive even a month when it's launched.

So much could have been better had they followed these practices from the beginning, instead of ignoring all 8 of them.

Water is wet.

In my experience tests are the primary mitigation for this issue.

I'm having an uphill battle trying to institute some of these practices on my current team. My takeaway is that it may not be as obvious as we think.