[Gluber]

You are confounding three separate skills. Finding the right abstractions is an art, whether you write clean code or not. Writing high performance code is another art.

A really good developer writes clean code using the right abstraction (finding those tends to take the most time and experience) and drop down to a different level of abstraction for high performance areas where it makes sense.

The fact that bad developers suck and write bad code no matter if they use clean code or not does not reflect on the methodology

[sarchertech]

If there are no hard measurements I can use to determine the value of "clean code" then I fall back on the results of produced by people who say they are writing clean code. There is no realistic way to objectively measure coding styles completely isolated from the people writing the code.

I personally haven't seen value from that coding style. There may be some platonic ideal clean code that is better than other methodologies in theory--it is likely that my sample is biased--but from what I've seen, the clean code style tends to lead most developers towards over abstraction.

[Gluber]

I agree but i think that mostly comes from Clean Code being kind of required reading for junior developers, that lack the experience to understand those concepts in context. No methodology is perfect, and there are always cases where one needs to break out of them, to know when to do that comes with experience.

For juniors which have no experience, any sane methodology is better than none, since otherwise you get even more of a mess.

That said, Clean code has some great advice, some mediocre advice and some frankly bad advice, but the authors point are largely irrelevant to 99 % of software engineering.

[ticviking]

I think this is the key insight.

It is easier to find an abstraction if we lay out what the program is doing all in long functions, that just "do what they do" until you figure out what needs to be abstracted.