I think we are talking about different contexts: I do not disagree if this is a big org and you are engineer N (> 100). With that said:
The previous company I worked in and others I’ve heard of were dysfunctional because organized like what you describe compared to their size. Backend engineers working on their API in isolation, without a good contact with end users, their business, and the UI, is the huge red flag in my case.
> Concretely, all services should have a "development mode" that allows them to exercise their business logic against mock or stub dependent services, in-process/in-mem databases, etc.
This brings only complexity and additional code in our case without any clear advantage (except code that’s easy to test but that’s circular reasoning). If your code is in the chain between a user action and the database, then the sooner you test the whole chain for side effects the better, without complex integration testing processes (with subs that will never be as accurate as the real thing). Bonus for being in the user’s shoes.
> If I'm working at a company, I expect that delivering business value means checking out, compiling, running, and testing a single process with no external dependencies.
Given the complexity and the number of dependencies of an OS running a browser and your editor/IDE, I don’t really see the point here.
> If this isn't the case, I will make it the case, before starting any value-delivering work.
That’s exactly the kind of issues I experienced at previous companies: engineers endlessly reworking the architecture until it’s perfect in their view with no rationale regarding real value (« it’s best practices » is not).
> spin up the entire universe of services on my laptop, creating a miniature staging or production environment, that's a problem that needs to be fixed.
This nicely summarize our different point of view: that’s a killer feature for me.
Again it really depends on the context and I’m not disagreeing with your experience, I disagree with how you state this like it’s universal rules of good software development without taking the context into consideration.