Notice the whole conversation in point 2 isn't about the user, or the business, or any goals. It's about "software quality" in the abstract, with no reference t

Notice the whole conversation in point 2 isn't about the user, or the business, or any goals. It's about "software quality" in the abstract, with no reference to the real world situation. This is why I think the idea of "bad code" is harmful: best practices are very specific to organizational goals (https://codewithoutrules.com/2017/11/07/no-such-thing-as-bad-code/ https://codewithoutrules.com/2017/11/07/no-such-thing-as-bad...). Given it takes time to get people to see the world in a different way (starting with external goals and working your way down to implications of code), it's unlikely you can convince people in the short term. So this devolves to an organizational problem. 1. You need someone to set priorities based on what the product and users goals are, which is to say a product manager. 2. Alternatively, you can go work for a startup. There you often get to see the opposite failure mode, where expediency rules and the result is often an engineering disaster :) 3. Finally, this particular failure mode is an intermediate experience failure mode. Experienced enough to notice when things aren't ideal, not experienced enough to know when it's OK to compromise. So you can also try to find a place where engineering leadership is sufficiently experienced that they'll make sure things gets done.