I'm sorry, but you seem to have read something in my post that was not there and then attacked a series of straw men.

You asked about listening to teachers without a track record and reading their books. I gave an argument that some people aren't worth listening to/reading, including the author in question here.

Tell me, what's wrong with Uncle Bob's latest book? All the suggestions are good.

I only bought his previous book (which is part of the reason I have a very negative view of Martin's work) but picking on some of the points in the article here that jumped out immediately:

It is important to remember that you don’t own the code, but rather the team does.

The degree to which collective code ownership by an entire team might be better than having more specialist roles is still an open question.

Over time, teams slowly grows better and better as well, resulting in team members will eventually know each others strengths and weaknesses.

Another great theory. It usually gets some cute title like "forming, storming, norming and performing" in the management textbooks.

What the article (and, I am therefore trusting, the book itself) glosses over is that many teams never reach the performing stage in practice.

When coding you should always aim to cause no harm in your project, by always aiming to get the error rate as close to zero as possible. This is done by simple writing tests. Tested code gives you more confident about your work, knowing the fact that what deliver is at top class and checked against errors.

The list of loopholes in pro-TDD arguments and the number of fallacies perpetuated by TDD advocates would fill at least a chapter of a book. To say that whether TDD is beneficial is an open question is putting it mildly.

Moreover, describing someone who doesn't buy the TDD hype as "unprofessional" is simply a crude ad hominem attack, which by the way targets almost all professional developers who do in fact work on software with bug rates an order of magnitude or more better than the industry average.

According to Robert C. Martin, if you work 40 hours a week, you should spend around 20 additional hours enhancing your own profession.

Ah, yes, I remember the management research about this one. It definitely showed that sustaining a 60-hour work week in a creative field was the best way to maintain performance, and found no negative consequences that quickly led to a net performance loss and ultimately to burn-out of the worker.

As a professional developer, you should know that being a software developer is a very intellectual and exhausting job. It is important that you don’t overwork yourself, but rather find a balance in life with your job.

Hang on a minute... Yep, we really did just talk about spending 60+ hours per week on work-related activities and then segue into the importance of getting enough rest.

If your superiors refuses to listen to you and does not take no as an answer, you should think about going one step higher. Even though going over someones head might feel uncomfortable, in the end it will deliver the best possible outcome for all involved parties.

If your superiors refuse to listen to you, it is their problem. If they do listen to you but then choose not to follow your recommendation, it is also their problem. Either way, you can if necessary ensure that your objections have been properly recorded, but it's almost certainly not your job as a software developer to second-guess a management decision and start playing levels of management off against each other. What happened to keeping a level head in a crisis and to being a team player?