Is Uncle Bob serious?

Unfortunately, in a field like software that isn't regulated (and IMHO isn't ready to be), you can say "no" up to a point, but if you continue to do that once management has determined that the answer should be "yes", you may simply get yourself fired and replaced by someone else who will give the desired answer. Unless it's a matter of moral judgement and you are willing to give up your job because you don't want to make what the boss wants you to make, software developers saying "no" rarely achieves much if management aren't listening.

Why not? After all, the safety of a pacemaker is largely because of the software it runs. In many cases, medical safety and software safety are nearly the same. And throughout our world, this is true in many industries. Driving. Banking. Our software today is our safety for nearly everything. It will only continue to grow this way.

Look, by whatever accident of history, programmers are currently in demand. If your shop is suicidal/trigger-happy on firing their valuable programmers, then just leave that place before that happens and find happier digs. Job #1 for any professional programmer should be to sleep well at night and not work overtime.

Stop making excuses for sloppy, rushed programming. Use your power to enforce good practices. Ah, but you say, "all that is relative, no one agrees on what the practices should be." More rationalizing; no more weak excuses! Every team can write unambiguous house rules that form the social contract over what definitions and expectations are regarding ready-ness, quality, done-ness, etc. Until the whole rest of the enterprise is behind you and aligned with you, all that matters is your team.

A right attitude is key. You, the programmer: do the simplest thing possible and use the scientific method when writing code through rigorous testing. Meaningful, working tests are proof.

After your team learns to hustle, then you have power to hold your product owner's feet to the fire! Question every bit of the requirements they set. Your designs should sell the work, embody those requirements, and draw out all the questions you have to the business - when you do a great job, they will ask and then answer all your questions and more for you. Sloppy, imprecise, crooked requirements must burn and be tested in the crucible of your design. You have the power to talk and argue and you have the power to say 'no'.

Reject any slow or unproductive tools, libraries, practices. Put tremendous, outsized, decadent effort into automating the hell out of everything mundane or annoying in your sphere. Always protect your brand/product/team: all vanity or pet tools/patterns/languages/CQRS-ES must eventually be jettisoned out the airlock whenever team productivity is being impacted.

People repeat this kind of sentiment all the time but is there anything to back it up? I know we've all run into to random bits of code we considered "low quality". But that can often be attributed to code that was written a very long time ago when programming practices were much different. At the time it was written it was likely high-quality code. It's like saying that a Gallbladder removal surgery from 20 years ago was "low quality" because it wasn't done orthoscopically, that technology was barely used at the time.

I'm starting to think that "tons of low-quality coders" is an industry myth to explain a variety of unrelated phenomena. The modern-day equivalent of the boogeyman. But let me know if I'm wrong.