[matai_kolila]

I’m sorry but this is complete nonsense; there is no pleasure derived from viewing “beautiful” code from the perspective of the consumer such as in your other examples.

A program is not like a car, a chair, or a house, and if any of this were brought up in a design meeting for code, you’d rightfully be laughed out of the meeting.

But it’s fine to disagree about these things up to the moment where you attempt to slow progress towards delivery for these values. At that point, the point at which functionality is hindered in any way by your artistry, are you now a problem on a development team.

There are plenty of productive ways to deal with problems, but make no mistake, on any competent software team you will be disabused of this “art” notion, not the other way around.

[dimmke]

>I’m sorry but this is complete nonsense; there is no pleasure derived from viewing “beautiful” code from the perspective of the consumer such as in your other examples.

You're taking it too literally. "viewing" in the case of software is "using". When I'm using a well designed, performant piece of software I can feel the art in it. When I'm using something thrown together I can feel that too.

[matai_kolila]

"Performant" is not the same as "well designed". What you feel is a pleasant UX, which is art, or closer to it at least, and would fit your analogy drawn against a chair or a car.

However what we're discussing here is how the code and otherwise hidden implementation is designed and built. OP is not a UX designer, OP is a software engineer, and should not waste time building things that are "beautiful" in that capacity.

UX and systems design are almost entirely unrelated, and should not spend time in one another's domain.