Beauty doesn't put food on the table, is my point, and I'm beyond sick of working with people who put "code beauty" before "code usefulness".
Ugly code that works pays bills. Beautiful code that doesn't work is, in a very literal sense, worthless.
I'm not against writing clean code (there's utility in that), but I feel like some folks lose the plot and quit their jobs when they can't make "beautiful" things anymore, and I think that's more often a sign of burnout than it is a desire to "return" to creating art.
Why is the dichotomy "ugly code that works" and "beautiful code that doesn't work"
Surely there's also "ugly code that doesn't work" and "beautiful code that does work." And I'd argue there's a lot of in between as well. Unless the software literally does exactly what it needs to do, no more, no less then there's also the variants of "works well, somewhat well, etc."
>Ugly code that works pays bills. Beautiful code that doesn't work is, in a very literal sense, worthless
what about good code that work? All places where I see your argument prevail, ended up to be not just 'ugly code', but unmaintainable code. And systems that cannot evolve at all.
Personally I don't call coding an art, but I've seen countless times how people people choose bad solution even though better one costs exactly the same, and in a long run - actually cheaper. And they _always_ use this argument - 'code is just a tool, if it solves the problem, it is good'. And then they either leave or have to spend weekends to write even more dirty code just to solve problem they wouldn't have in the first place if they spent a little bit more time thinking about the code.
Don’t mistake “beautiful” code for “clean” code. Clean code has value in its ease of maintenance, it’s easy to work with. “Beautiful” code falls into the completely arbitrary land of “what is beautiful?”
Wars have been fought over defining beauty, but the important thing to note is that beauty is orthogonal to function. Clean code has clear criteria and value, beautiful code does not.
