Discussion on: What professionals think about Clean Code ?

I feel the post is more about this:

Functional programming has some rather elegant abstractions around manipulating lists of things too, and it was easy to feel proud of expressing a complex transformation, in a few lines of careful crafted maps, filters, and reduces. Yet somewhere is the background of my perceived ‘clean code’ lies the actual problem I am trying to solve, buried under layers and layers of ‘beautiful’ code.

than what Clean Code strives for.
Simply put the cleanest of code is dumb, its simple, its tested and is obvious. Like other said, you need to put in time and effort to get to this sort of state.

The blog says:

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?

That might be true until requirements change, or a bug is actually found, then you need to change your "good working code". If it isn't clean, or was done "just enough", you end up with a mess.

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.

I could apply this idea to literally anything that isn't directly working toward requirements.
I followed this line of thinking I shouldn't refactor/test/use-better-tools/learn because it's not directly working toward the requirements.

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.

Code is cleaned up over time only if it actually gets improved after every change. This task is made easier if the code is clean.

It seems to be the blog is addressing making code "beautiful and elegant", especially since it refers to functional programming, where code can end up extremely dense for the sake of elegance. Clean Code doesn't go down that route, it goes more the utilitarian route. (it also uses OOP code as examples)

Both are talking about "clean code", but both are really addressing different problems with different solutions, as such comparing them is kind of like comparing apples to oranges to a degree.

I don't think clean code is hard to achieve at all, the real challenge is keeping it clean over time. Requirements change, bugs are found and code needs to be refactored over-time to match those changes.