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.
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.
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.
For what it's worth, I actually agree that good software development genuinely is driven by vibes a lot of the time. Sometimes we get to formalize them into laws and rules, but we learn the vibes before we learn the rules; and if we only learn the rules but not the vibes, we don't reliably manage to apply them or overapply them. So I don't view that as an insult, but as a differently-phrased description of my actual view.
So if you want me to view it as ridiculous, you're gonna have to actually engage with the point.
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.
> This is pretty representative of what I'm calling the flamewar style
It would be good to have a HN dictionary of terms. The normal internet definition of a flamewar is "a hostile, prolonged argument on the internet that devolves into personal attacks, insults, and aggressive behavior". I said "all coding is vibe coding". Not really a personal attack or aggressive, is it? Glad to know now there's a separate HN definition for this term though. Thank you for correcting my terrible behavior. (That was sarcasm, by the way, not an aggressive attack; I know this can be hard to interpret)
> It's enough to offer a different view, or explain what you think a more correct view is.
I already offered a different view, in detail, and their response was to double down on the opposite of that view. I would be reiterating the same original point. In order to express the inherent flaw in the view, I associated it to another view most people today find abhorrent. It's high risk, but I have nothing to lose, because they already disagreed with my point.
> 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
I mostly comment on HN to inform the casual viewer that there is a different view than that of the majority echo chamber. I don't need the person I'm replying to to agree with me. I'm trying to reach the person whose brain isn't yet shut down to logic and reason. I admit sometimes it comes off as dickish, which is regretful, but hopefully still makes my point.
> because it breaks the implicit contract of curious conversation
Almost nobody on the internet has agreed to such a contract. Most people's brains implicitly believe that whatever they already think is correct, unless presented with some irrefutable proof, or argued by a person they implicitly trust. Many people are curious, but not so curious as to want their mind changed by strangers. Which is why people lean on the heuristics of popularity, authority, success, etc to choose what to believe. Most people don't have curious conversations, they have disagreements and agreements.
HN is the epicenter of the tech contrarian, here to disagree with any prevailing wisdom and consider any claims that don't sound like "common sense" as suspect. You've built a wall to keep out intelligence and evidence, and inflate the power of the crowd to make certain opinions seem more valid, depending on who happens to have more traction in the comments. I believe it's a feature built into this platform to increase engagement and controversy to increase site traffic.
You can't be dickish (to use your word) on HN. If you keep doing it, we'll end up banning you the same way we ban other users who won't follow the site guidelines.
Fortunately you can make any of your substantive points without doing that. Since this will also be more effective at your stated goal of informing readers, there is no reason not to.
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.
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.
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.
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/
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.
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.
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.