Bonus: good tests can also serve as technical documentation.

Though I have to disagree with the notion that documentation is as important or more so than code.
Documentation is certainly near the top of the list and often undervalued. I’ve worked on a project where documentation was lacking and it was painful to say the least.
Without documentation, changing or adding features can be a nightmare. Investigating bugs and offering support is also very difficult. But without code, you have nothing. No product, no users, no value.

There are (inferior) substitutes for documentation: specialized team knowledge, general technical expertise. These alternative pools of knowledge can be leveraged to create and improve documentation incrementally.
There’s no replacement for the actual functionality of your applications.

The point is that you’re not fixing the problem, you’re just masking it (and one could even argue enabling it).

The same way adding another 4 lane highway doesn’t fix traffic long term (increasing highway throughput leads to more people leads to more cars leads to congestion all over again) simply adding more RAM is only a temporary solution.

Developers use the excuse of people having access to more RAM as justification to produce more and more bloated software. In 5 years you’ll likely struggle even with 32GiB, because everything uses more.
That’s not sustainable, and it’s not necessary.

Many of the programming languages that are regularly the butt of everyone’s jokes don’t just allow you to use them badly, they make it easy to do so, sometimes easier than using them well.
This is not a good thing. A good language should

• be well suited to the task at hand
• be easy to use correctly
• be hard to use incorrectly

The reality is that the average software developer barely knows best practices, much less how to apply them effectively.
This fact, combined with languages that make it easy to shoot yourself in the foot leads to lots of bad code in the wild.