[dmurdoch]

So you've listed houses, cars, watches, food. All these things indeed serve a purpose as well as allow for creativity and expression.

But the difference is, all those things have sale values that DIFFER based on that creativity and beauty. Code does not. My customer does not care if my backend code is beautiful, and neither does my CEO because it won't make more money.

> Is a dish or menu designed by a chef not art? Is a house designed by an architect not art?

Of course I see the art in those things, and in response i'll pay a lot more for a Frank Lloyd Wright than a mcmansion. But the customer of my B2B CRUD app does not care if my code looks like a FLW or a mcmansion. They care if it works.

[dimmke]

>all those things have sale values that DIFFER based on that creativity and beauty. Code does not.

I wouldn't be so sure about that. I certainly prefer to use software that has a nice interface, is fast and responsive and has thoughtful features. I remember the first time my iPhone opened a pop up at just the right time asking if I wanted to share a wifi password with my Mac. Wow! Delightful. And I am willing to pay more money for such things.

>But the customer of my B2B CRUD app does not care if my code looks like a FLW or a mcmansion. They care if it works.

What is "works"? I'm not being disingenuous here. The software development process is often plagued by things like scope creep, unreasonable asks from stakeholders, cutting things for budget or time etc...

"works" is a subjective concept in your hypothetical customer's mind. Likely molded by you or your project manager setting expectations, pushing back on feature requests, etc...

My real point is, it's not just the value of the consumer or "customer". But the artist as well. It's the satisfaction you can get from designing a performant service that handles requirements and has the capacity for future expansion, etc...

Just because some people are philistines doesn't make the creation any less valuable as a piece of art.

[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.

[w23j]

Your writing reminds me a lot of "Zen and the Art of Motorcycle Maintenance".

'The real cycle you're working on is a cycle called yourself. The machine that appears to be "out there" and the person that appears to be "in here" are not two separate things. They grow toward Quality or fall away from Quality together.'

[hinkley]

> My customer does not care if my backend code is beautiful

Apple can only sustain the high margins they do because you’re wrong. Some people care a great deal. Some of those people have deep pockets. If none of your customers seem to feel that way it’s probably because they are Apple customers.

But you also have companies like Anker and at certain points in their history Sony, Samsung and perhaps LG. They got it. At least for a while.

People here don’t complain about Apple for silly reasons as much as they used to. But I’ve been laughing at people jealously predicting their imminent demise while cashing dividend checks ever since their shares were $40 pre-split (7x and counting IIRC). I’m going to get to retire at least a couple years early just on AAPL, even having done dollar cost averaging.

> B2B crud app

Ah. Businesses have a weird split brain problem and it’s difficult or impossible there. They want custom software for less than or around the price of off the shelf solutions. The OTS ones can be beautiful and occasionally get away with it. If you care about art of even ergonomics you’re gonna have a bad time. I encourage you to seek out a new vertical.

[matai_kolila]

> Apple can only sustain the high margins they do because you’re wrong. Some people care a great deal.

Are you suggesting that some people care a great deal about how pretty Apple's code appears, despite having zero way of knowing anything at all about that as a consumer?

[pixelrevision]

They do start to care when it stops working or it takes forever to change due to it being a mess. This is the natural state most projects end up at unless the devs are putting in a ton of extra effort to keep it clean, organized and maintained. Devs that are thinking about keeping things beautiful, succinct and performant are much more likely to do that.

[hinkley]

My Observer bias of late has been about open or nearly open feedback loops. People don’t adjust their strategies when the consequences come due later. I’ve been on a number of projects and seen a few more where management keeps turning screws to get stuff faster and then goes pikachu face when the whole thing grinds to a halt. Few if any of them see themselves as the agents of chaos in this situation. It’s not their fault, it’s someone else’s. And even if you can document it, it doesn’t sink in. Because that was something they did years ago and we don’t think about old things.