Can you expand on why you feel that way? A few people I respect have told me they got a lot out of it, so I'm curious to hear what you think is wrong with it.

IMO, the advice is all over the place. Sometimes it's good or almost, but often obvious or accepted (maybe a sign of the times?). Sometimes it's bad or ambiguous. If you can make that call, you are likely experienced enough to not need it. If not, how would you know what to follow, and what to ignore?

There's also a shocking lack of evidence that applying "clean" code rules actually leads to, well, "better" code (more maintainable, or even just more readable). In fact, in some cases, the rules kinda clash.

So in the best case, you read it, think about it, and maybe pick up one or two new things. In the worst case, it leads to pointless zealotry that can be quite toxic, especially when forced onto other people.

In short, save your money. Clean code is a grift, like many self-help books. You do have to give to Uncle Bob, he recognised that in a gold rush it's better to sell shovels (as the saying goes).

This has been linked elsewhere already, but is a better critique than I could do in a comment: https://qntm.org/clean

There's A LOT I could write about Robert Martin and Clean Code, but in short:

- focused on the readability of small functions rather than the readability of the whole program. This gives you unreadable programs containing lots of small readable blocks of code. I argue this is wrong. We care about programs first and foremost.

- arbitrary rules ("ideal function should have zero arguments", "functions should be two to fours lines long"). He hasn't run studies, he hasn't provided any proofs. Nothing scientific, it's just some guy's opinions.

- his code examples speak for themselves, in a bad way. Check out the link posted in a sibling comment. They show a person who's trying to put their ideas in code for the first time (or, at the very least, first time trying to write non-trivial code) and it's becoming obvious that those ideas don't work. But the person persists and publishes the book regardless.

- he hasn't really achieved anything in software apart from selling books and consultancy services. Name one impressive piece of software that he wrote, like a version control system, or a database, or a high performance JSON parser. All he's done is (as far as I can tell) CRUD software. That's not even enough for an "appeal to authority" argument.

In the words of a classic, Robert Martin is a "self-appointed expert". I would be very skeptical about following his advice.

> A few people I respect have told me they got a lot out of it

I don't mean to offend you. If I had to guess, these people you respect work on trivial software, just like me or Robert Martin. It's software you can write using almost any ideas or methodology. It doesn't matter what you use, because the task is so simple. Read data from a frontend, write to a DB, read from a DB, send back to frontend. You can do this using assembly x86, Fortran, OOP (whichever flavour), FP, whatever P.

So when people say "they got a lot out of it", I take it this means "I do things a lot like Robert Martin (as opposed to a mythical idea of <<spaghetti code>> that's meant to make the code unmaintainable), and it seems to work; I deliver features and I get paid". And that's fine, I guess. You can make your life harder by following Robert Martin's advice and still achieve your goal.

The problems begin when you need to start writing "real" code (rather than CRUD/plumbing), like anything that's supposed to have good performance, or actual CS problems like TSP, path finding, and so on. Robert Martin proved he can't write a readable prime number generator even when performance is not an issue.

My advice is to keep respecting the people you respect but focus on the CS and mathematics fundamentals instead. IMO there's little to nothing in Clean Code that will make you a better developer.