Don't write clean code, write CRISP code

It makes sense if you read the article.

Correct: the primary objective. Code that does what it's supposed to, bug free.

Readable: strive to write code that will be understandable by others (and your future self). Review what you wrote and be your own critic when it comes to clarity.

Idiomatic: Write code the way people in your community expect to read. Don't surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already.

Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don't DRY things up just for the sake of it. Don't do too many things. Be parsimonious.

Performant: be aware of RAM (a bit of a letdown).

The last point was disappointing, as I was expecting something about coding to data structures when it matters. Instead the author went on about being aware of memory.

It's definitely something that people overdo. But sometimes, especially with things like terraform, you have to struggle against the DSL to avoid having thousands of lines of repetitive code to do what could done in 100. I'll go quite far to avoid the situation I saw at at previous company, where they had 36k lines of trash to run a few data centers. Deploying a new data center was next to impossible.

A summary.

Correctness: the primary objective. Code that does what it's supposed to, bug free.

Readable: strive to write code that will be understandable by others (and your future self). Review what you wrote for clarity and be your own critic.

Idiomatic: Write code the way people in your community expect to read. Don't surprise them with your own quirky and clever conventions, when there are well established and perfectly acceptable ones already.

Simple: Your code should do what it says it does directly, with no funky side-effects. Repetition is not always a sin, don't DRY things up just for the sake of it. Don't do too many things. Be parsimonious.

Performant: be aware of RAM (a bit of a letdown, was expecting "code to data structures" advice).

---

Author concludes with a few interesting take-away points. Some highlights (paraphrasing):

- don't trust foolproof software engineering methodologies sold using a neat backronym.

- words like "clean", "simple", and "readable" are as vague as "freedom", "justice", or "equality".

- neat slogan like "don't repeat yourself" or "clean code" are moot.

- correctness above all else.

- tests only prove that the code can pass the test.

- No info is better than bad info. No tests is better than bad tests.

- all software has two types of bugs: those you've found and those you have yet to find.

- we all want readable code, but we have different definitions of "readability".

...

> Since we’re adding new backronyms every day, I propose SIMPLE.

> S - Spaghetti: write tapestry of code like a chef.

> I - Interlinked: if the project has modules, they should all depend on each other (we are strongest when we can depend on one another).

> M - Micromanaged: if the product owner doesn’t expect reports in the daily stand-up, do they even care?

> P - Perplex: diversity for the codebase.

> L - Lazy: Bill Gates once said “I choose a lazy person to do a hard job, because a lazy person will find an easy way to do it”, for example, without testing, collaborating with team members, or ensuring the feature works with anything else in the codebase.

> E - Opinionated: because I believe E should stand for opinionated and everyone else will have to work around this with adapters. But E should mean Opinionated because Uncle Bab said so.

Considering most software already fails on the first aspect, do the other four points really matter at all?