I generally take the view that authors have the best insight on their intention, so I apologise for my misreading.
> I find pretty big differences in code that's written to meet the lowest bar of "just pass the tests" vs code that's written with the intent of keeping its state space small, methods tidy, and overall complexity limited.
I think maybe this is where the misunderstanding arises. I'm used to TDD which amongst other things places pressure on the codebase to remain testable. The things that make code testable also, roughly speaking, make it reusable as well (test code is just code, after all). But more important than any one practice or tool is people just giving a damn about doing the work well.
This might be an example of Goodhart's Law: if someone throws a test suite over a wall[^] and says "here, make these pass or you're outta here", then the motivation to cut corners is going to be intense. Attempts to create control loops over humans that rely on mechanical behaviour by humans tend to fail. Steering wheels don't have families and mortgages, wing flaps aren't thinking about their next promotion.
The best discussion I've read about the problems of using measurements and targets to control (in the engineering sense) skilled workers is Measuring and Managing Performance in Organizations by Robert D. Austin. He elegantly demonstrates that the less directly-observable the work, the more destructive attempts to externally control it are. Which fits with my updated understanding of what you intended to say.
[^] this doesn't have to be a current wall, either. It can be the wall of elapsed time: the flaky tests of yesteryear can be a very particular kind of curse.
> I find pretty big differences in code that's written to meet the lowest bar of "just pass the tests" vs code that's written with the intent of keeping its state space small, methods tidy, and overall complexity limited.
I think maybe this is where the misunderstanding arises. I'm used to TDD which amongst other things places pressure on the codebase to remain testable. The things that make code testable also, roughly speaking, make it reusable as well (test code is just code, after all). But more important than any one practice or tool is people just giving a damn about doing the work well.
This might be an example of Goodhart's Law: if someone throws a test suite over a wall[^] and says "here, make these pass or you're outta here", then the motivation to cut corners is going to be intense. Attempts to create control loops over humans that rely on mechanical behaviour by humans tend to fail. Steering wheels don't have families and mortgages, wing flaps aren't thinking about their next promotion.
The best discussion I've read about the problems of using measurements and targets to control (in the engineering sense) skilled workers is Measuring and Managing Performance in Organizations by Robert D. Austin. He elegantly demonstrates that the less directly-observable the work, the more destructive attempts to externally control it are. Which fits with my updated understanding of what you intended to say.
[^] this doesn't have to be a current wall, either. It can be the wall of elapsed time: the flaky tests of yesteryear can be a very particular kind of curse.