I'm going to have to disagree with the entire premise of this piece.
If you are a cabinet maker you have many individual clients who all want what you're producing. They each have their own budget and preferences that you can work with to get them something they want to buy. The incentives and constraints are clear here. If you can make something the client wants at a price and quality point they can afford you will do well.
Many (most?) software developers create a product to satisfy the needs of many customers and non-customers simultaneously. Furthermore you almost never interact directly with customers; instead developers interact with a panoply of different business interests such as engineering managers, product managers, project manager, product owners, etc. Even worse software doesn't have to be done to ship it as it can always be fixed "later". With the advent of Agile, Scrum, and SAFe it's clear what the business wants is not someone good at a craft; they want an assembly line.
So what are the incentive structures and constraints here? Every other person has incentives for career advancement, bonuses, raises, etc. Most people are too far removed from customers to be directly affected by them. How many times has a cabinet maker been told that the hope chest they're working on for one client also needs to double as a bank vault. Oh and by the way it needs to be done by the end of the quarter (right after layoffs of course) because they are hoping to be bought out. Code bases end up being a fractured mess of bad abstractions, infinite abstractions, and rewrites because developers are trying to accommodate the impossible demands set forth by the business in a way that doesn't cause their job to be abject misery.
TLDR: most software developers are not expected to be craftsmen (or women). The company determines, through incentives and constraints, the quality of code it will produce. An individual software developer risks burnout if they think quality above and beyond what the company allows is within their responsibilities or capabilities.
What I've seen mostly is developers bringing complexity, then cutting corners after that because they don't want to deal with it. In Coders at work, Douglas Crockford said to spend the sixth cycle - whatever the cycle is - on refactoring. It's a sound advice if you care about technical debt as an engineer. Spend some time to revisit the code architecture to see if it still fits the problem you're solving. Instead of spending three cycles on something that could have been done in one because of how fragile everything is. Or having a long list that is tied to the same root cause.
Sometimes it means redo your React marketing website in Node and EJS (or the equivalent) instead of trying to make it SSR too.
> In Coders at work, Douglas Crockford said to spend the sixth cycle - whatever the cycle is - on refactoring. It's a sound advice if you care about technical debt as an engineer.
My point is that very often it's not up to engineers. If a company doesn't incentivize this refactoring and engineers have to - as some sibling comments suggest - inflate their estimates then the code base will deteriorate over time. Even if your team sets up a policy of doing refactoring ~15% of the time this will be overridden by business interests more often than not.
This is essentially a corollary of Conway's Law. You should not expect code bases to be better than the business incentivizes it to be. I'm speaking from personal experience here; this is burnout territory. Keep in mind these are very general observations and every company is different. In some companies what you and Crockford suggest is possible. I'd wager it's the exception rather than the rule though.
If you are a cabinet maker you have many individual clients who all want what you're producing. They each have their own budget and preferences that you can work with to get them something they want to buy. The incentives and constraints are clear here. If you can make something the client wants at a price and quality point they can afford you will do well.
Many (most?) software developers create a product to satisfy the needs of many customers and non-customers simultaneously. Furthermore you almost never interact directly with customers; instead developers interact with a panoply of different business interests such as engineering managers, product managers, project manager, product owners, etc. Even worse software doesn't have to be done to ship it as it can always be fixed "later". With the advent of Agile, Scrum, and SAFe it's clear what the business wants is not someone good at a craft; they want an assembly line.
So what are the incentive structures and constraints here? Every other person has incentives for career advancement, bonuses, raises, etc. Most people are too far removed from customers to be directly affected by them. How many times has a cabinet maker been told that the hope chest they're working on for one client also needs to double as a bank vault. Oh and by the way it needs to be done by the end of the quarter (right after layoffs of course) because they are hoping to be bought out. Code bases end up being a fractured mess of bad abstractions, infinite abstractions, and rewrites because developers are trying to accommodate the impossible demands set forth by the business in a way that doesn't cause their job to be abject misery.
TLDR: most software developers are not expected to be craftsmen (or women). The company determines, through incentives and constraints, the quality of code it will produce. An individual software developer risks burnout if they think quality above and beyond what the company allows is within their responsibilities or capabilities.