What I take from your comment is that it doesn’t matter to business what the code looks like. But it does matter to engineers that they have buy in on the desig

What I take from your comment is that it doesn’t matter to business what the code looks like. But it does matter to engineers that they have buy in on the design choices. And that feeling like the code was designed in ugly / foreign ways decreases motivation and productivity. I don’t think that the answer is for engineers to just “suck it up” and wait until there aren’t pressing feature demands (which usually never happens). But instead, we should spend time reading the code our coworkers and past employees have written to understand the design and philosophy behind it. If the design of something you’re working on isn’t good by your standards, your productivity will still suffer if you leave it how it is. Especially if you have good taste. The feeling of deep authorship - like, “this is my garden and I’m proud of it” is something worth cultivating even if you only care about output. I can close way more tickets in a day if I feel at home & in control with a codebase. And that’s something that matters to business as well as the engineers on the ground.