This is an extremely good way of putting it. Doing some of this at the requirements stage if possible can be very helpful too, because you can detect nonsensical or conflicting requirements before you even write any code.
I've been working on a notion tentatively called "example driven development". Use specifications to generate code. Kinda like compiling swagger docs to implement an HTTP server.
My first such effort was using the BA developed HL7 interface documents (swagger for HL7) to code generate our implementations. Worked great.
1: https://www.amazon.com/Specification-Example-Successful-Deli...
His conclusion is the money quote for me:
"...your job is finding ways to simplify that input space as much as possible."
I do this. Instinctively? I feel more or less alone in this practice.
My prime motivator is to do less work. Less is more. Concision is a virtue. Blah, blah, blah.
The trouble with my strategy is that simple is hard. Much harder than kanban themed JIRA mediated velocity maximizing slapdashery. Also harder to measure.
So compared to my peers, it looks like I'm moving in slow motion.
To illustrate, someone who fixes the same code pathway multiple times is scored higher than someone (like me) who fixes it (mostly) right the first time.
The tortoise vs the hare.
--
"If I Had More Time, I Would Have Written a Shorter Letter"
-- Blaise Pascal https://quoteinvestigator.com/2012/04/28/shorter-letter/
--
Aside: I was a QA/Test manager for a while. I really cared about this stuff, back in the day. Now it seems no one cares.