I haven't actually read Clean Code, but according to what I've read on the internet about it, it seems to make some reasonable points.
About Muratori's rant, I have a few objections.
Thinking about how to make code not messy, whatever that means to you, is time you could have used to write code to figure out how to structure your program. You spent time that should have been spent thinking about the problem, on thinking about the code. In other words, you have wasted time.
The end goal is to have good working code, not clean code. if you have the ugliest code in the world, but it runs efficiently, and has no bugs, then it didn’t matter right?
Those two points only hold true as long as you write code once and never again need to modify it. If you have code that is messy and ugly, and you haven't touched it in a few months, and now have to implement a new feature there, even if it runs perfectly for its originally intended purpose, then you're in a worse position than if you would have spent some time making the code easy to read, modify and reason about.
Code will naturally clean up over time, prematurely cleaning it is worse than wasting time, because it may lead you down wrong, time consuming paths.
My experience is that code quality tends to degrade over time and it requires great commitment, discipline, and agreed-upon rules to keep it in good shape. Maybe Muratori has only worked with better developers than myself and thus our experiences differ.
I do agree with the 3rd and 5th points, although I think that the phrasing of the 3rd point is a bit unfortunate.
You make excellent points - seems to me it's a case of not mentioning what your world looks like. It seems to me a lot of our development arguments online boil down to different experiences.
If all your colleagues write good, buff y free code, tests aren't that important, neither is clean code.
If your colleagues don't know what a function is, and development is buggy and takes ages, then it's super useful.
That's why I love the talk "The hidden assumption of agile" by Fred George.
Agile is built on clean code, but nobody bothered to say it at the time because they all wrote clean code by default.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I haven't actually read Clean Code, but according to what I've read on the internet about it, it seems to make some reasonable points.
About Muratori's rant, I have a few objections.
Those two points only hold true as long as you write code once and never again need to modify it. If you have code that is messy and ugly, and you haven't touched it in a few months, and now have to implement a new feature there, even if it runs perfectly for its originally intended purpose, then you're in a worse position than if you would have spent some time making the code easy to read, modify and reason about.
My experience is that code quality tends to degrade over time and it requires great commitment, discipline, and agreed-upon rules to keep it in good shape. Maybe Muratori has only worked with better developers than myself and thus our experiences differ.
I do agree with the 3rd and 5th points, although I think that the phrasing of the 3rd point is a bit unfortunate.
You make excellent points - seems to me it's a case of not mentioning what your world looks like. It seems to me a lot of our development arguments online boil down to different experiences.
If all your colleagues write good, buff y free code, tests aren't that important, neither is clean code.
If your colleagues don't know what a function is, and development is buggy and takes ages, then it's super useful.
That's why I love the talk "The hidden assumption of agile" by Fred George.
Agile is built on clean code, but nobody bothered to say it at the time because they all wrote clean code by default.