I don't agree on Joel for everything but his bakery clean analogy https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... feel spot on for me.

Same with bakery, clean code doesn't means that you need to have no duplicates, solid, etc. You can work with dirty codes, until it gets too dirty to work on and you need to start cleaning, by which will takes considerable of time. Otherwise if you want to make it as clean and spotless as possible, it'll take considerable time and also you need to do that every time changes applies.

Consider renovation projects, you won't see they mop the floor everyday to the spotless level, they'll maybe sweep and clean it to the point where it's acceptable to operate. As you get better and with better tools, you can make less mess and less, but there'll be trash somewhere.

And same in code, you clean your code to an acceptable level, otherwise the code will be too dirty over time and hard to be worked on, and as you get better you'll make less dirty code. Problem is, nobody can know / agree on the acceptable level in programming which makes things hard.

Robert Martin and John Ousterhout have a conversation about Clean Code[0] versus the approach in A Philosophy of Software Design.

> Clean Code repeatedly gives very strong advice in one direction without correspondingly strong advice in the other direction or any meaningful guidance about how to recognize when you have gone too far.

My take is that that Clean Code has some good advice for enterprise style software projects. It is incredibly prescriptive but sometimes that's not such a bad thing. In my experience it's worth it in uncoordinated/inexperienced teams who would otherwise produce an undisciplined mess of code.

Stick with it if it works for you as long as you don't go around bashing other people for not doing it the "right" way as many clean coders do. The dogma surrounding what amounts to a set of preferences and design trade-offs is what makes Clean Code so off-putting, especially if you have slightly different preferences.

[0] - https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...

No. If you're doing it right, it shouldn't take much extra time, and it will make your code much more readable and maintainable.

A lot of the "work" is automated these days anyway. Mainstream languages have hinters/linters or static analyzers that will catch many of these issues, and some (like TypeScript) have incredibly powerful static analyzers that will fix the issues automatically when they can.

Cheat sheet on Clean Code: https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988c...

You are not supposed to treat it as a gospel, following every guideline. Instead, it is a collection of ideas presented to you, so that you can decide if you want to use them (or not!) in your day-to-day work.

In general, software development is not a profession where you learn how to do things and do them, occasionally refreshing your skills. It is a perpetual problem solving field (not without its routines), and a continuous journey. Creativity, personal opinions and exchange of ideas play an integral role in this profession.