It was referring to coding as being the same as any craft. You are being hired to do a job, you don't know how long your code lives and needs to be maintained. "The buyer is a lady, I will not make the effort to make that hammer last long, how often will she use it" is not someone I'd do business with.

My point is do your job well of course but dont pretend the output is something more than it is

At the end of the day, it's a paycheck for something you hopefully enjoy. And no matter how well crafted you think it is. Someone else is going to come along in the future and think its crap

Again going back to the chip on the shoulder

Somewhere there is a line between pragmatic and negligently flippant.

There are reasons to care about code quality beyond a chip on one's shoulder. Scalable, extensible, and readible systems retain optionality and can provide substantial business upsides that were unknown (and often unknowable) at creation.

Conversely, analysis paralysis can prevent progress. It's a balance.

Organizationally, energetic stupid programmers (those who fail to see around corners and fail to carry the lessons of these principles with them in their work but still have high "output"), left unchecked, will drain organizations of talent.

We work hard to avoid this heavy delivery bias on our teams because the metrics-focused race to the bottom is a very tough thing to undo. Quality is much easier to keep than to add.