His lectures and books really are harmful. Beginners read them and get the impression that you can design good software by following a bunch of simplistic rules of thumb. In reality, you need to understand what trade-offs you're making when committing to certain design decisions and, even more importantly, you need to be able to discuss this with other people.

For example, it's not "small functions are good", it's "when you make a function smaller, here are the benefits and here are costs". Primitive, sloganistic thinking is the bane of software engineering profession right now.

Testing is his singular solution for everything.

I think it was this video, but I can't watch it all the way through right now -- https://youtu.be/ecIWPzGEbFc

Testing definitely has value, but when testing you always have to make the assumption that you can’t test everything, and then the trick is deciding what to test versus what not to. I think people forget this and focus on having every function tested, every interface having coverage, etc.

The problem with that (tautological) statement is that too many people read it as: "you can't test everything, so don't bother testing anything".

I find it much more convincing if someone were to say, “test what’s easy” instead, that’s all.

Not to say there is not still a place for manually written unit tests.

And I say all this as someone who has pursued this very idea of property testing side effects for years and in the end had to admit failure. It just is too much work get right (eg uuids being generated not unique, to name just one example), and your test runs become incredibly slow, which is a killer in many REPL-driven workflows.

Expressing your state in terms of pure functions of input events, as can be done with an FRP like Reflex, means you can test all your logic purely. You can be confident that you'll only request to launch the nukes when the nukes need to be launched.

Then you have to make yourself confident that, when the system asks the nukes to launch, it sends the right signal. But that's mockable by running the system attached to device that reads the signal and reports its correctness.

And making sure the nukes take off, aim correctly, and land on their target is not my department (says Werner von Braun).

They are awful to work with and be around. All of those concept I mentioned have benefits in them, but not as a religion. Medium programmers lack nuance and deep experience and are dismissive of those that do, they see it as weakness. When their favorite technique doesn't take them to the holy Nirvana of software, they lash out at other, less zealous developers and blame their lack of discipline.

Completely shitty people - I just hope they grow out of it. But they are seductive in their intensity and (bad) managers love to hear how they have a simple solution to all their woes - rather than software development being inherently difficult (because you only have to do a specific hard things once, but that's another discussion!)

Another OO-evanglist who belongs to this camp is Ron Jeffries.

For a textbook example of how much of a snake-oil OO-evangelism is, checkout the sudoku solver fiasco involving Ron Jeffries and Peter Norvig (you'll find plenty of search results regarding this).

1. stumble over differences from their normal approach

2. catch on and use it everywhere (Stockholm syndrome? Testing limits?)

3. finally find places it doesn't work and can apply judiciously

Given that in our profession we're constantly learning and experimenting, Uncle Bob is still doing that to this day.

That there are drawbacks to the REPL feedback loop is true. But they aren't the drawbacks Bob claims to have found here, because he ceased investigating at the point he felt his priors were confirmed.

Saying that his posts are harmful is a bit of a stretch.

Why on earth would you think that?

Saying that his posts are harmful is a bit of a stretch.

Mentor your first few people who keep defending rookie mistakes with "But Uncle Bob said..." and you might change your mind about that.

Bob Martin says some sensible things, but he also says some things that are at best debatable and at worst outright contradicted by the evidence base, and he says all of them with great conviction and presumed authority so that his target audience can't tell the difference. That alone makes him dangerous as a source of advice.

I have been developing for 54 years. I have been through all manner of design philosophies, from Structured Programming, to Object Oriented Programming, to Agile, to TDD along with hack-it-till-it-works.

If you don't do the engineering, which he does not teach, you are going to struggle.

I believe this is a harmful post.

So I agree with the parent ... his writings are in many cases harmful. They're a mix of good and bad, but often net harmful.

Look at how much growth happened in the last 15 years.

A set of principles for program design, specifically OO (and some flavors of OO at that), but some of the ideas are general enough to apply to most languages and paradigms.