There's rarely a right way to write code, though there are definitely plenty of wrong ways. :)
Every SWE goes through phase 1, which is writing yourself into a corner by not thinking about maintainability and interfaces. And then phase 2, where you write such a complex interface that it collapses under its own weight. Only then do you get to the point where you're even aware of the need to balance interface complexity and upgradeability vs. code velocity.
Usually at that point you mock some stuff up quickly to see where the pain points are, and then go back and do a more maintainable design. And try to convince the manager that the mockup is *not* production-worthy code, because it's full of shortcuts and empty of tests and light on error handling.
Even if you're coding something the right way for the *current* requirements, it may not be the right way when requirements change. Which they do.
But if you're writing code for money, there are finite resources. So you never get to do everything the way you want. Sometimes you skimp on error handling. Sometimes you skimp on tests. Sometimes you tunnel holes in your API to get at that one state variable that just isn't cleanly exposed and yet absolutely critical to patching some other bug. All those things add risk. And at some point, you need to mitigate at least *some* of that risk, hopefully *before* it costs you downtime / money / customers.
It's always a hard sell to management.
And it's often a hard sell even to the engineers. If you want to get promoted, you're far better off writing a spiffy new feature rather than decreasing technical debt.
