It feels like for that to work you need to be managed by people that appreciate this always to the top, to the point where this affects hiring, on boarding, etc. you also need a compatible business model.
Quality code where you can get away with it not being is a fragile thing (in the fragile/anti fragile) sense.
I wonder if the hill to die on is getting a good architecture that minimises the impact of bad code not as bad.
Yeah, the strength of a business is tightly coupled to the principles and culture underlying that business.
I've found many speak to caring about code quality, but in the startup scene it seems quite rare for people to actually live it.
People obviously talk about linting and syntax, but appropriate separation of concerns, abstractions, coupling and so on are way more impactful. Unfortunately those things are also difficult to quantify without knowing the context. Hard to train people on these things, it takes a lot of thinking and experience. But common threads around best practices and principles start to appear.
I've mentored/managed many people and always enforced quality as a cultural element of our teams, and you can see that those kind of principles become "viral" in a sense. They get adopted by those you work with, and they impress those principles upon others down the line.
To your last point, I do think proper separation of concerns is probably the most important principle. Such that you can easily fix any mistakes that are made.
Microservices are a good vessel for this in theory, but it's possible to build a distributed monolith in microsevice form. e.g. exposing low level apis and having a high level of chattiness. So yeah, those boundaries need to be well defined haha.
Quality code where you can get away with it not being is a fragile thing (in the fragile/anti fragile) sense.
I wonder if the hill to die on is getting a good architecture that minimises the impact of bad code not as bad.