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.
> 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...
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...
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.
https://www.youtube.com/watch?v=tD5NrevFtbU
Casey specialises in game engine research and development
https://caseymuratori.com/about
And has an ongoing course on computer performance for programmers.
Few books are truly a total waste of time, and reading often has benefits even when you disagree with the author. But once you put all caveats aside: yes, yes it is
FWIW - no it's not an absolute waste of time. But, it's arguably more dogmatic than is realistic for most teams.
And I would say it's certainly not required for an elegant readable and high quality codebase. But it has ideas which are worth absorbing.
Good companies will recognise that this should be a balance and provide their developers enough time to do both to a satisfactory degree. Sometimes the devs will have to push for this, and will meet resistance, but as with everything in engineering, nothing is black and white.
Write the best code you can, under the circumstances you can. It's a delicate balance.
Code smell.
If it worked and passed the “clean” test but still didn’t scratch an ego or worse, did something ypir peers or boss didn’t think of as a solution, then it would “smell”.
I would have thought only “unclean” code could “smell” but even the “cleanest” code could “smell”.
It made work as rigorous as shooting an arrow in the dark. But the shame of smelly code would have brought the whole thing to its knees so I am relieved such pertinent problems are being so addressed so aggressively by the truly smartest of humanity.
Logic issues? That’s okay. Code smell? GTFO
Large systems benefit from clear architectural patterns, whereas small systems see little benefit
Performant code is often obscure and messy, it shouldn’t be forced into a “clean pattern” for the sake of it
Clean architecture greatly affects how changes are made in the system. If 20 places need to be updated to add a feature, and that’s something that needs to be done often, then maybe refactoring it would improve this workflow.
At the end of the day it’s a tradeoff that programmers need to make
“will cleaning this up make it better or worse for us”
Practically, if a PR comes in and it's either a one-shot script or something small, I wouldn't bother too much about anything as long as it works and doesn't smell really bad (e.g. every variable is of single character).
But it's another story if 1) the code is entangled with business logic, or 2) it's part of a medium-large project. In case of those I'd demand very detailed documentation and passing some linter at least.
* The total time it takes to perform a large refactor. This should take no more than 4 hours, 2 ideally, to code and qualify with high confidence using test automation.
* Speed of code style enforcement. If it takes more than 1 minute total effort to impose a code style evaluation (including human time) then it is wrong, even for a very long application.
Every function should do only ONE thing. Use layers to separate concerns, and again, each function in each layer should do ONE thing.
After that, go wild.
All pretty standard stuff, and you can set it up in a day, a lot of the boring work can be done by LLMs, so you won't have to waste a lot of time on it.
I find that just doing the above things gives a project enough stability, and it gives the developers enough courage to refactor with confidence and ship relatively fast.
At the end of the day Software Architecture is a craft, if a system is not working for you or your team (or you don't understand why you are doing something), then you want to look at changing it.
I have a strong feeling is that architecture methodologies work as long as you are a very small and super committed team (see: startup where you all are invested into the success of the product), but they shatter to parts in a bigger corporate environment where acquisitions, mergers, and rewrites happen every other month, and you need to adopt the new framework/language/methodology/scrum/kanban/whatever.