However, there's a slight problem: We don't need that level of solidity. The rest of the stack is comparatively less solid, so his time would be better spent getting ten easy, frequently-hit bugs out of the rest of the codebase, rather than get one unlikely-to-hit bug out of his.
He hates producing code that's not up to his standard, but when our fleet of cars consists of a Lamborghini he built and a beat-up Yugo some other guy built, I'd rather my friend changed the rusty oil of the Yugo rather than make sure that all the bolts on the Lamborghini are within tolerance.
This is a fascinating theory on programming ageism. It's common knowledge that most software buyers undervalue tech debt and the costs of maintenance/upgrades. That presumably translates for less interest in planning, experience, and thoroughness compared to speed.
And most of that isn't controversial, but I rarely see it raised in the context of preferring young and inexperienced devs. I suspect there's at least some truth to it, because highly self-aware software companies seem uncommonly willing to poach older experts.
This. I don't pump ridiculous amounts of code, but what I do, Works, and is mostly bug free or easily repairable. Thus I have a reputation as a guy who gets things done.
Companies should really be aware of the maintenance overhead caused by fixing old badly done code.
Maybe it's the market dynamics. Most code bases are new (their age is not measured in decades) so the organizations have not gained the institutional understanding what a sinkhole of profits badly executed code is. Some companies use this as a business model an charge "maintenance costs" and such things so there is also the pathological motivation to maintain this status quo of "implement cheaply, fix expensively"