Don't write clean code, write CRISP code

I have to ask, what's the point of telling coders--presumably experienced ones if they are familiar with the concept of clean code--to try to get their code to work?

"Have you tried getting it working?"

(I really think the author must mean more than that, given the segue into testing one's tests? Why do that, if the thing is working? Or does one assume at all times, forever, that it's broken? That's not really mentioned)

So IMO the energy that goes into justifying the word probably isn't worth the carnival ride to the exciting world of status quo, so to speak.

"Correct" as a word has also had quite a social shadow side ever since Political Correctness became a thing at the very least. What it amounts to is de facto social resistance to the topic of whether one's creation is correct.

These days it's even more encumbered by the ongoing reconciliation dialog regarding "incorrect or just different?" E.g. divergence from pack or narrative in various ways being not so bad a thing by default anymore, especially insofar as the resulting support structure makes new room for new ideas that move past the worst parts of who we all used to be.

But that's just one aspect; telling a coder to check that their code is correct is also an awkward way to communicate on its face, especially if that's the first answer to "how can this model help me to be a better coder" for example. It's going to drop the author into literal mansplain territory for huge swaths of audience. It's like first principles, for people who don't know what code is meant to accomplish.

Just some ideas though.

So, where's the value of having this word in there? Does the model really need the word at all? If so, why?

Besides, Bob Martin even mentions this in his book "Clean Code". Page 35:

> The problem with this statement is that it's hard to know what "one thing" is...

He finally concludes that a function is only doing one thing if:

> you can extract another function from it with a name that's not merely a restatement of its implementation.

Which is just dumb. Let's call our function `compileCProgram()`, well according to the second heuristic this is only doing one thing. Anyways, if even the guy who wrote the book about clean code admits that it hard to figure out what one thing is, I'm inclined to say you may be slightly disingenuous here.

And then you create job security for yourself!

Nobody will dare going on your turf or I mean the beautiful junk you created. With all the complexity and smelling code in place only you is “smart enough” to know how everything function. Since people that love to code would be so horrified you will be the only leader and maybe at some point the only expert and junk man, I mean coder of this junk. Since now you are so integrated to a part of how the system works nobody can fire you. You can still advance in your career. Thanks to how much complexity and buzz word you added to the pile of junk you can demonstrate you know what you are talking about to no so good managers in tech. Words like micro services, kubernetes, Kafka, istio, Falco, Vault, (add the last flavor)… Even though all this have no real value for the current state of your projects. Barely doing X events/s and making complexity of the system goes from O(n) to O(n^2).

But who cares? You have the most secured job and your career possibly is great.

C - Confusing: Write code that is hard to understand, ensuring that only you can maintain it, thus securing your position in the company.

H - Hodgepodge: Mix programming paradigms, libraries, and styles to create a unique blend of code that reflects your artistic side.

A - Arbitrary: Make decisions about architecture, data structures, and algorithms without any specific reasoning, allowing for a more spontaneous and whimsical development process.

O - Obfuscation: Deliberately make your code difficult to read and comprehend by using cryptic variable names, nested loops, and a lack of comments.

T - Tinkering: Constantly make small, undocumented changes to the codebase to keep your teammates on their toes and to give yourself an excuse to fix "bugs" that you secretly introduced.

I - Inconsistent: Use different naming conventions, indentation styles, and language features throughout your code to keep things interesting and unpredictable.

C - Cluttered: Avoid modularization and organization, and instead cram as much functionality into a single file as possible. This will create an exciting challenge for anyone attempting to decipher your masterpiece.

Embrace the CHAOTIC way and create a memorable, one-of-a-kind codebase that will leave a lasting impression on your colleagues and ensure your job security!