Earlier quoted context omitted.
My craft is not leaving a dumpster of a solution to the next people to look at my code when business logic inevitably changes. If someone's solution to seeing my code is "we gotta re-write it", I have either failed or a much more novel solution was discovered that makes my code irrelevant. I hope it's not the former.
Your “craft” is not to write code, it’s to solve problems. If you can’t be proud of the problem you’ve solved, you are no engineer. That’s the main difference between an engineer and a scientist.
> Your “craft” is not to write code, it’s to solve problems.
Writing code is part of solving problems.
The quality of code has an impact on the various aspects of how a group of people solve problems.
As a small example - consider onboarding time for a codebase/system. Longer onboarding time means - lower profits end of the day for the organization (I'd also argue that longer onboarding times correlates higher talent attrition). And code quality has a strong influence on onboarding time.
Code quality has an impact on the "debuggability" of your systems. How quickly can you fix stuff when things go wrong?
Code quality has an impact on the "deployability" of your systems. If your code is well-done it is easy to deploy, redeploy, etc.
I can cite maybe 10 more properties crucial to org health, which are influenced at least partly by code quality.
So, "the problem" is not as simple as it may seem at first glance.