While it's true that the end user ultimately cares about whether the code works or not, the argument that code purity is a self-limiting decision ignores the lo

While it's true that the end user ultimately cares about whether the code works or not, the argument that code purity is a self-limiting decision ignores the long-term costs of not prioritizing code quality. Code that "works" in the short term may have unforeseen consequences down the line, such as increased maintenance costs, difficulty scaling, or even security vulnerabilities. It's also important to consider the impact on other developers who may need to work on the same code in the future - writing messy code can create confusion and make it harder to collaborate effectively. More to it, the idea that working only with "good code" is a luxury decision assumes that writing clean, well-structured code is inherently more time-consuming or costly than writing messy code. A well seasoned engineer should be able to balance both because they know that better architecture will ultimately save time and money in the long run by reducing the need for debugging and maintenance, and making it easier to add new features.