3 ms·

The "tasteful solves" is codified cargo culting. The software industry has a tendency to anthropomorphize software while playing to the ego of the programmer. T

The "tasteful solves" is codified cargo culting. The software industry has a tendency to anthropomorphize software while playing to the ego of the programmer. The programmer imagines they are creating a "beautiful" artistic expression. Good code becomes "tasteful", as a software artist must have "good taste" to tell the good software from the bad software. Good quality lacks "bad smells", because a good artist has fine senses (and everybody must like the same smells). "Fine craftsmanship", in code as in woodworking, means your finely-crafted work is "technically superior", so you can charge more money for something that could've been made cheaper and faster and done the same thing. But it's a lie. Nobody's paying you to make paintings. They're paying you to build machines. The comparison between "making working software" with "taste" always devolves into bikeshedding and subjective opinionism, uses subjective human feelings to describe what should be objective and functional, isn't rooted in scientific rigor, and detracts from the real purpose of the thing. The work doesn't actually get better by trying to apply artistic principles to engineering. It just feels better for the people making it. Once you make the machine work, then you can go about gilding the lily. But this is unromantic, unsatisfying, boring. Since the inmates run this particular asylum, we end up with a benchmark that tries to accurately mimic the human ego as applied to software design. Thus the new Gods create their digital Adams and Eves in their image.

Dban1 4mo ago
As time passes we will have fewer and fewer literati
Eridrus 4mo ago
Most engineers are wrong (I obviously am the true arbiter of taste), but that doesn't mean there isn't better and worse code. "Does it work" glosses over a bunch of things: is it fast, cheap, secure, reliable, easy to understand, easy to modify? And that's just for server software where you've nailed down all the functional requirements. Determining what the functional requirements is it's own question. And all these other non-happy path requirements are somewhat in tension with each other, so what is ideal in one environment is not necessarily ideal in another. And in particular, "easy to understand/modify" is truly subjective. Different people have different ideas of what easy to understand means. Even if we get to a world where AI is writing all our code, "easy to understand/modify for the AI" is still an important question. We've probably all seen prototypes that collapse under their own weight of slop by now.
- sally_glance 4mo ago
  Well actually there is a reasonably objective standard defining software quality criteria on the source code level (ISO 5055). They also define 29 criteria for maintainability: https://www.it-cisq.org/coding-rules/ https://www.it-cisq.org/coding-rules/
  - Eridrus 4mo ago
    See, this goes back to the, all software engineers besides me are wrong, because I see this list and do not think it is anywhere close to a sufficient list for good quality software. The thing about all these criteria is that sometimes they are important, sometimes they are not. This "standard" exists for the sake of code analysis vendors to be able to have some sort of shared taxonomy, but also provide a fig leaf of standardization to their products.
    - sally_glance 4mo ago
      Very true. As with all standards, there will always be people who disagree. We still mostly follow them either because we're forced to or because the effort required to establish another standard doesn't outweigh the benefits. Personally I've always been a proponent of project specific standards, but after many years of discussions about more or less individual preference I've come to think that maybe settling on something global isn't the worst idea. Not that I think it must be this one in particular, but it's not the worst start either.
9dev 4mo ago
I may be paid to build a machine, but I am a human and take pleasure in arbitrary acts of vanity. I value elegance, and will always favour elegant solutions in engineering and the design of machines, virtual or physical. That’s the reason why I buy Apple products in private, because I value the design over the exorbitant prices they charge; and it’s the reason why I mull over code that’s already functional until it’s pleasing my ideas of elegance. I can come up with all kinds of justifications and explanations why the code I’ve written a certain way is objectively better too - understandability matters to the next guy after all - but I won’t be ashamed for taking a certain pride in my work, even if nobody other than me ever values it. That’s fine. When the LLMs finally take over coding altogether, you’ll have your raw, functional code. Won’t be long anymore. But for now, I’m a human, and I will do human things.
FeepingCreature 4mo ago
Taste is just quality by instinct. At sufficient (and not all that long) timescales, a tasteless product will be more and more difficult to make work at all.
- 0xbadcafebee 4mo ago
  So software engineering quality is vibes. All coding is vibe coding.
  - dang 4mo ago
    Could you please not post in the flamewar style to HN? We're trying to avoid that here, and we've had to ask you this many times over the years. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
    - 0xbadcafebee 4mo ago
      It's not a flamewar style comment, and I think you know that. I was responding to someone's suggestion that software engineering quality is determined "by instinct" - as in, by feel, as in, vibes. It's a pointed argument about conventions of the software industry, made by repeating what the person said using different words that mean the same thing, to try to get them to see how ridiculous their argument is. You have warned me several times over the years over valid arguments I've made, with no rhyme or reason other than you personally don't agree with my views (or two people downvote it). It would be nice if you didn't throw your weight around so casually, but then again this is your world, not "the community"'s.
      - dang 4mo ago
        This is pretty representative of what I'm calling the flamewar style: > repeating what the person said using different words that mean the same thing, to try to get them to see how ridiculous their argument is Especially when you do it in a snarky way, without any clarifying information, it comes across as belittling and adds a layer of edginess that isn't needed. There's no need to "get [someone] to see how ridiculous their argument is". It's enough to offer a different view, or explain what you think a more correct view is. In fact, if the other person senses that you're trying to "get them to see how ridiculous their argument is", or indeed to "get them" to do anything at all, they usually react primarily to that quality, and only secondarily to any argument—because it breaks the implicit contract of curious conversation. This is how threads get into downward spirals.
phreeza 4mo ago
I think this is a complete misunderstanding of what people mean by taste in software engineering. Taste is more like the System 1 response one builds to code over time, which (ideally) captures the quality of the software beyond surface level, so things like maintainability, composability, readability, likelihood of hidden bugs. This is completely different from the question if the code fulfills the immediate task at hand, but also not the same as pure aesthetics.

Dban1 4mo ago

As time passes we will have fewer and fewer literati

Eridrus 4mo ago

Most engineers are wrong (I obviously am the true arbiter of taste), but that doesn't mean there isn't better and worse code. "Does it work" glosses over a bunch of things: is it fast, cheap, secure, reliable, easy to understand, easy to modify? And that's just for server software where you've nailed down all the functional requirements. Determining what the functional requirements is it's own question. And all these other non-happy path requirements are somewhat in tension with each other, so what is ideal in one environment is not necessarily ideal in another. And in particular, "easy to understand/modify" is truly subjective. Different people have different ideas of what easy to understand means. Even if we get to a world where AI is writing all our code, "easy to understand/modify for the AI" is still an important question. We've probably all seen prototypes that collapse under their own weight of slop by now.

sally_glance 4mo ago
Well actually there is a reasonably objective standard defining software quality criteria on the source code level (ISO 5055). They also define 29 criteria for maintainability: https://www.it-cisq.org/coding-rules/ https://www.it-cisq.org/coding-rules/
- Eridrus 4mo ago
  See, this goes back to the, all software engineers besides me are wrong, because I see this list and do not think it is anywhere close to a sufficient list for good quality software. The thing about all these criteria is that sometimes they are important, sometimes they are not. This "standard" exists for the sake of code analysis vendors to be able to have some sort of shared taxonomy, but also provide a fig leaf of standardization to their products.
  - sally_glance 4mo ago
    Very true. As with all standards, there will always be people who disagree. We still mostly follow them either because we're forced to or because the effort required to establish another standard doesn't outweigh the benefits. Personally I've always been a proponent of project specific standards, but after many years of discussions about more or less individual preference I've come to think that maybe settling on something global isn't the worst idea. Not that I think it must be this one in particular, but it's not the worst start either.

9dev 4mo ago

I may be paid to build a machine, but I am a human and take pleasure in arbitrary acts of vanity. I value elegance, and will always favour elegant solutions in engineering and the design of machines, virtual or physical. That’s the reason why I buy Apple products in private, because I value the design over the exorbitant prices they charge; and it’s the reason why I mull over code that’s already functional until it’s pleasing my ideas of elegance. I can come up with all kinds of justifications and explanations why the code I’ve written a certain way is objectively better too - understandability matters to the next guy after all - but I won’t be ashamed for taking a certain pride in my work, even if nobody other than me ever values it. That’s fine. When the LLMs finally take over coding altogether, you’ll have your raw, functional code. Won’t be long anymore. But for now, I’m a human, and I will do human things.

FeepingCreature 4mo ago

Taste is just quality by instinct. At sufficient (and not all that long) timescales, a tasteless product will be more and more difficult to make work at all.

0xbadcafebee 4mo ago
So software engineering quality is vibes. All coding is vibe coding.
- dang 4mo ago
  Could you please not post in the flamewar style to HN? We're trying to avoid that here, and we've had to ask you this many times over the years. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
  - 0xbadcafebee 4mo ago
    It's not a flamewar style comment, and I think you know that. I was responding to someone's suggestion that software engineering quality is determined "by instinct" - as in, by feel, as in, vibes. It's a pointed argument about conventions of the software industry, made by repeating what the person said using different words that mean the same thing, to try to get them to see how ridiculous their argument is. You have warned me several times over the years over valid arguments I've made, with no rhyme or reason other than you personally don't agree with my views (or two people downvote it). It would be nice if you didn't throw your weight around so casually, but then again this is your world, not "the community"'s.
    - dang 4mo ago
      This is pretty representative of what I'm calling the flamewar style: > repeating what the person said using different words that mean the same thing, to try to get them to see how ridiculous their argument is Especially when you do it in a snarky way, without any clarifying information, it comes across as belittling and adds a layer of edginess that isn't needed. There's no need to "get [someone] to see how ridiculous their argument is". It's enough to offer a different view, or explain what you think a more correct view is. In fact, if the other person senses that you're trying to "get them to see how ridiculous their argument is", or indeed to "get them" to do anything at all, they usually react primarily to that quality, and only secondarily to any argument—because it breaks the implicit contract of curious conversation. This is how threads get into downward spirals.

phreeza 4mo ago

I think this is a complete misunderstanding of what people mean by taste in software engineering. Taste is more like the System 1 response one builds to code over time, which (ideally) captures the quality of the software beyond surface level, so things like maintainability, composability, readability, likelihood of hidden bugs. This is completely different from the question if the code fulfills the immediate task at hand, but also not the same as pure aesthetics.