What professionals think about Clean Code ?

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.

I guess the entire point of the book is to just try to make your code readable for others, not just to yourself.

About Casey's writing I'd say that he is probably one of the best developers alive, I've never came across a code that would clean up over time.

I like to practice a few of its principles because I know how hard is to read someone else's code and be completely lost for hours on simple things.

I believe that single purpose functions, few parameters, size and scope of classes and functions matter and most importantly: comments lie. A bug fix will not fix a comment.

It is impossible to write perfectly clean code, but is very good to have a few sets of rules to help you manage an always growing application.

Surely it is not as important when you are a single developer or working on a very small team (2-3 people), but becomes increasingly important as your team grows.

I don't know that I qualify as a 'professional' (I'm paid to manage computers and networks, not to code, but I still code a lot), but my thoughts on this are quite simple:

Have a well defined standard for both structure and formatting of code in your project that helps with readability for as many people as possible, and stick to it.

The issue is with the people who act like medieval crusaders regarding this type of thing, trying to force their specific ideals on others while not even considering listening to other people's resonans for why they do things differently.

It's really difficult to write code that's clean. Even for those of us who've been in it for a while. That book seemed pretty good back when I read it, and it's fun to read, but honestly there's different techniques to focus on depending on where you are in the piece of code you're working on and the project in general.

Rather than 'clean' code, I tend to focus on making my code clear and making easy-to-understand abstractions.

You can follow advice like only writing necessary comments or limiting how many arguments functions take, and still end up with code that's fairly difficult to understand. I think the book goes into this as well, but thinking about software architecture and structuring your code well tends to have more of an impact on how understandable your code ends up I reckon. Stuff like creating clean abstractions, breaking your code it into logical sections and doing your best to make sure that every part does just what it's meant to, no more and no less. The good thing about this is that even if you're working with an existing codebase, knowing and actively thinking about this can still be really useful.

Most of the time when I start a coding project, I grab a pen and paper and just start drawing boxes and lines. What are the specific modules/sections of the code, what classes exist (the boxes), and what parts of the code talk to or use parts of each other (the lines). How many boxes need to exist so that you and other devs can clearly understand what each one contains at a glance, and how do you simplify communication across your code so that you have the least number of lines going between different boxes all over the place?

Or maybe you've got some other requirements, like how do I structure things to make it as easy as possible to add new managers/controllers/output formats/protocols -- every project's different, sometimes sacrificing how 'clean' the code is helps you achieve different goals. Even when you're not using objects at all, thinking about the different 'logical sections' of your code and how to design them can help a lot.

e.g.:

I'm writing a chatbot and there's a global manager, a database module, a user-account module, a display module, and a module that loads plugins, how do I make sure each module can talk to the modules it needs to without cross-linking absolutely everything to everything? Maybe an event-dispatch system that everything sends events through, maybe each module links the global manager as this.manager and routes everything through that, maybe just separating the app into two or more separate programs that communicate in a totally different way? How do I plan on extending the code in the future, and what's most important to me?

Software architecture in general and levels of abstraction are both good things to look into, working with different projects and seeing how they're designed is good for those. Looking into how to make your code easily unit-testable also does a lot of this work for you. The skills you use for this are really general, mostly just organising information into groups and displaying it as clearly and consistently as possible (e.g. graphic design, UI design, and even writing documentation relies pretty heavily on those skills), so they're also really transferable to other work you do around coding and tech.

Once you dive deeper into the writing-code side, the specific advice around stuff like simplifying inputs/outputs to functions, commenting well, and sticking to a consistent code style throughout your project become especially useful. Both are good sides to focus on

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.

I've read the Clean Code book and use it as a bible.
I think it is very practical and very useful.

What senior developers tend to forget is that their knowledge is very rarely teachable and easy to follow over time.

Clean code is. Also, it is super widespread in many different domains and that is a very powerful thing when talking about conventions and readability

I feel like poor management and morale is responsible for the ugliest code I have seen throughout my career. Clean code is all about consistency; as soon as most of the team is at the f*ck-it point, then everything tends to crumble really quickly. People may talk about fixing it later, but you're so glad to be done working on the dumpster fire of an application that it never happens. Consultants get brought in to fix the codebase and the process repeats, as they leave a bunch of half-assed kludges for the next development team to avoid for the next few months.

People need to be allowed to have a little pride in their code. Or at least I do. It's definitely a fine line, but if it feels like a punishment to be stuck in some crappy repository, the downward trend is likely to continue until it becomes abandonware.

There's a bit right near the end where Uncle Bob addresses this point. He points out that clean code is more effort than unclean code, and there's a trade-off. You shouldn't strive to make your code clean, you should strive for clean enough.
That and he also points out you can't write clean code. You have to write dirty code and clean it up using refactoring. Which is where Martin Fowler's book Refactoring comes in!

And heck yeah it matters, but it generally doesn't matter immediately. If you write a 250 line behemoth that doesn't explain a thing, with no tests, somebody else two years down the line is going to have to spend a day just working out what is going on. That person then has the choice to refactor or not. If the code was cleaned up at the time...

I'm on Clean Code right now. And the reason for it was simply an event that happened on my work. I left a few days because of a mission and one of my colleagues was in charge of implementing a feature. I could have done in almost one day, because I am familiar with that particular pieces of the code. But one week passed and the feature was half implemented. I asked myself why this happened and the answer for me was bad code and bad architecture.
The bad code made hard to my colleague understand what exactly was happening there. The bad architecture made hard to my colleague to understand where she had to make the changes.
So, Yes! Clean Code ALSO matters!
And remember that this is not the only book from Uncle Bob. He has another called Clean Architecture. So it is not the end of your journey to right better code.

Another experience that I had is pretty much what Uncle Bob describes in his book. We had a product where the code simply rot up to a point that it was not possible to add any other feature. If that were the main product of our company, we would be broken by now. Fortunately, it wasn't.

Our job isn't just solving a problem. If you are really professional, you will solve the problem on an economically, responsible and sustainable way.

It's good to know and adopt as part of your developer practice, just don't be too extreme to treat it as the only way or the highway.