I find it to be more nuanced. Your code has to work correctly in a bunch of scenarios. Some are very simple to see, others are nuanced corner scenarios.

A good developer will write code that passes many of these scenarios, but even the best will miss some. And an inexperienced developer might write code which passes some basic scenarios.

So, “this code works” is really a range, not a binary condition.

"Code either works or it doesn't" is more like a mindset and a pholisophy rather then truth or a fact.

In the context of this article and this thread, I was just reminded about this approach.

Hating or loving software development, other peoples code, or approach is sort of meaningless.

At the end of the day, we all get paid to build software and it is our job to make the software functional.

As long as the code works and does what it is supposed to do, thats all that matters.

My high school computer science teacher (almost 30 years ago that is) used to say: "A program that 'almost works' is like a plane that 'almost flies'".

Now I'm just trying to mentally picture what a mode of transportation that almost flies would work like via animal metaphors - would it almost fly like a chicken? or like a flying squirrel?

> software either works or it doesn't

You don't use threads in your software, do you?

If you like ruthless simplicity you should try functional programming.