But yes, you are right with your summary. It is based on an observation that some of the solutions I've seen developed are developed inside our own heads only. Or are written down in documents or slack channels or meetings where we talk, we agree on things but they are not enforced anywhere. Or where we dream "what if's" scenarios, put all those side by side and vote, based on our power of imagining the outcome, and decide what to next implement and spend our time with.
And part of the problem, and I say part as I don't have access to everyone's environment to see how they work at their computer now that we work from home, but part of that is a real fear of the computer (or lack of mastery, I donno), thus the bits about changing code often, some ideas on how to achieve that and make the environment you're using to write code, explore the project and your ideas your own, regardless of how it looks from the outside.
As an extreme example, one client was sending us both the authentication library as .c and .h files to be compiled on our side and an add-on to be installed on a tool we were already using. When there was a new version of the .c and .h files, which always happened as this authentication feature was under active development, the add-on changed too. There were instructions as PDF files on how to install this add-on, which were slightly different every time. When the project started up, before one could send any commands to it, the authentication procedure had to be successfull.
My thinking was that, since I don't work on that part of the system and the features that I'm responsible for only work after the authentication was successful anyway, I can identify the part of the code that does the authorization and hard-code an authorization successful implementation, which was simply returning <q>true</q> from the correct function. I would thus reduce the number of steps needed to reload the system after a code change and thus reduce the reload time. In short, I would just assume the authorization worked and concentrated only on my stuff. I didn't commit this code, of course. But to my surprise, even though I've presented this to colleagues and even PM, the reply was that well, we sorta have to work with the whole system and make sure the whole system works. And yes, we did that, only on our daily activities we didn't have a reason to test the authentication part every single time, dozens of times per day since we didn't change it, we worked on the part of the code that comes after authentication. But no luck. So a lot of time was spent and is spent with these steps.
I say "an extreme example" as automotive software seems to e to be a special example. I wrote about it on another post on my blog. It got pretty long and uncovered all the messiness. But that's another topic.