A 35mm lens forces you to move. You can't zoom, so you have to walk toward the thing you want to photograph. That small walk asks for commitment, and commitment asks you to see the picture first, or you end up a foot away from something that made no sense to approach.
A 10ms latency budget works the same way. You can't throw compute at it and hope. You have to understand what you're doing: why this query touches the database three times, why this function rebuilds state that hasn't changed.
Both situations create the same pressure: articulate what you're actually after, or stay stuck.
I shot on primes for years before my wife gave me the Tamron 28-75. The zoom made it easy to adjust the frame without moving, which meant I could avoid committing to a perspective until after I'd already taken the photo. The photographs from those first weeks were technically fine and also somehow all about nothing.
The years with the 35mm had trained the opposite instinct. The question of where to stand came before the question of how to frame, and the answer to where to stand usually carried the answer to what I was photographing.
In software, well-drawn interfaces do the same thing. A function signature or a module boundary forces you to decide what a thing is before you write what it does. Most of the bad code I've written was code where I skipped that decision and hoped the implementation would sort itself out.
There's something uncomfortable about constraints: they make the gap between what you intend and what you can actually execute visible. The information can be unpleasant, but its accuracy tends to be more useful than staying comfortable.