Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time.
So what's the value here? Single responsibility?
That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.
Concepts that are worth explaining to beginners, but most code will follow it by default.
Seeing it in job descriptions is more an indicator that a company has an inexperienced lead more than anything else.
"That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s."
Has humanity progressed so much that we no longer forget the lessons of the past?
That would indeed be a good thing but I am not so sure of it.
Some people are just bad.
Doesn't change my point that the debate is long settled, SRP is incredibly well known and the de-facto way of coding today.
Except I see people getting it wrong constantly, even in the comments here. Its not about keeping code together that's related in functionality, this about keeping code separate by stake holder. For example, if you have two bosses that keep asking for changes related to their departments, you keep their relevant code separate, so when you have to keep updating it for one boss, you don't break the code related to the other boss, and vice versa.
Does it work? I don't know, never been in this situation.
https://en.wikipedia.org/wiki/Single-responsibility_principl...