> You don't have to pick on camp over the other. In my opinion, if you want to make a good product for a user, you should also treat the code you produce for them as your craft. There is no substitute for high quality work.

Exactly, thank you for putting it like that.

So far it’s been my observation that it’s only the people who think like the OP who put the situation in the terms they did. It’s a false dichotomy which has become a talking point. By framing it as “there are two camps, it’s just different, none of them is better”, it lends legitimacy to their position.

For an exaggerated, non-comparable example meant only to illustrate the power of such framing devices, one could say: “there are people who think guns should be regulated, and there are people who like freedom”. It puts the matter into an either/or situation. It’s a strategy to frame the conversation on one’s terms.

I agree with OP's distinction. However just because you see software as a means to an ends, doesn't mean that you don't feel that quality and craft are unimportant. You can see the "craft" oriented folks as being obsessed with the form of their software. A "craft" oriented engineer might rewrite a perfectly functioning piece of software to make it what they perceive to be "easier to reason about". I consider most software rewrites to be borderline malpractice.

I think the kind of surface level rewrites that people rag on are pretty rare, at least in my experience. Realistically code that's impossible to understand, underdocumented, and lacking in proper abstractions is also deficient code. If you've ensured that the code is "good enough", you will likely hit a bug or feature request that is hindered by the poor structure and understanding of the code.

It's totally fine to say "the code works, that area is stable, let's not mess with that code". I make those kinds of tradeoffs on a near daily basis. But let's be real, "perfectly functioning code" is an ill defined, moving target. What looks like perfectly functioning code to a sibling team or a PM, could be a massive liability to someone who actually knows the code.

But then again I'm writing OS and performance critical code. A 1 in 1 million bug is easier to ignore in a throwaway log viewer website.

With bad code it’s often almost impossible to improve the functionality or correctness or performance of the code, without first rewriting parts of it.

The most productive teams I've seen (eg at Jane Street) rewrite things all the time, and still move faster than any "normal" teams I've seen. I remember when I interned there over a decade ago, they were already on like the seventh? version of their incremental computing framework, and were building a new build system. But they were also incredibly effective at getting things done both on a per-engineer basis and in terms of making money.

That example doesn't work well. All regulations come at the cost of freedom, and every freedom comes at the cost of regulations. While it isn't a strict binary (either 100% freedom or 100% regulation), enacting regulations do interfere with freedom. So this isn't just framing, it demonstrates a relationship between the two concepts, which may become relevant down in the discussion, if it already hasn't.

Regulation can cause freedom to be balanced differently between parties. For example, regulating smartphone manufacturers can result in more freedom for users. It’s not true that regulation necessarily reduces freedom overall (to the extent that that can even be graded). Just like rights, freedoms aren’t absolute, and one’s freedom often impinges on someone else’s freedom.

The increase of freedom of the users is an indirect side effect, intentional or not, which, as you put it, can happen, or not. But a direct effect, which is guaranteed to happen, is the loss of freedom of the manufacturer. Whether that's a good thing, that's another topic.

The increase of freedom of the slaves is an indirect side effect. But a direct effect, which is guaranteed to happen is the loss of freedom of the slaveholder.

That's certainly a perspective, specially given how slavery is often regulated into law.

But I digress, there's a plentiful discussion to be had about the ethics and morality of freedom/regulations, but my point is how there is, in fact, a dichotomy between both and it isn't just framing. Which, in a sense, you just corroborated.

> People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly, and is obviously created by people the care deeply about the quality of the product they produce (you know, the kind that acutally read bug reports, and fix problems quickly).

I would classify all of those as "capabilities and limitations of your product"

I read OPs "good code" to mean "highly aesthetic code" (well laid out, good abstractions, good comments, etc. etc.), and in that sense I agree no customer who's just using the product actually cares about that.

Another definition of "good code" is probably "code that meets the requirements without unexpected behavior" and in that sense of course end users care about good code, but you could give me two black boxes that act the same externally, one written as a single line , single character variables, etc. etc. etc. and another written to be readable, and I wouldn't care so long as I wasn't expected to maintain it.

>but you could give me two black boxes that act the same externally, one written as a single line , single character variables, etc. etc. etc. and another written to be readable, and I wouldn't care so long as I wasn't expected to maintain it.

The reality of software products is that they are in nearly in all cases developed/maintained over time, though--and whenever that's the case, the black box metaphor fails. It's an idealization that only works for single moments of time, and yet software development typically extends through the entire period during which a product has users.

> I read OPs "good code" to mean "highly aesthetic code" (well laid out, good abstractions, good comments, etc. etc.)

The above is also why these properties you've mentioned shouldn't be considered aesthetic only: the software's likelihood of having tractable bugs, manageable performance concerns, or to adapt quickly to the demands of its users and the changing ecosystem it's embedded in are all affected by matters of abstraction selection, code organization, and documentation.

But those aesthetics stem from that need for fewer bugs, performance, maintainability. Identifying/defining code smell comes from experience of what does and doesn’t work.

> I wouldn't care so long as I wasn't expected to maintain it.

But, if you’re the one putting out that software, of course you will have to maintain it! When your users come back with a bug or a “this flow is too slow,” you will have to wade into the innards (at least until AI can do that without mistakes).

Good abstractions translate directly into how quickly the devs can fix bugs and add new features.

But the thing is that someone has to maintain it. And while beautiful code is not the same as correct code, the first is impactful in getting the second and keeping it.

And most users are not consuming your code. They’re consuming some compiled, transpiled, or minified version of it. But they do have expectations and it’s easier to amend the product if the source code is maintainable.

The single line single character program, after a certain level of complexity, will no longer have the same behavior because it cannot be maintained.

If it’s software that will never be modified, sure it doesn’t matter.

> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.

Exactly. A lot of devs optimizing for whether the feature is going to take a day or an hour, but not contemplating that it's going to be out in the wild for 10 years either way. Maybe do it well once.

> but not contemplating that it's going to be out in the wild for 10 years either way

I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.

>I think there are a lot of developers working in repos where it's almost guaranteed that their code will _not_ still be there in 10 years, or 5 years, or even 1 year.

And in almost all of those cases, they'd be wrong.

I think I calculated the half-life of my code written at my first stint of Google (15 years ago) as 1 year. Within 1 year, half of the code I'd written was deprecated, deleted, or replaced, and it continued to decay exponentially like that throughout my 6-year tenure there.

Interestingly, I still have some code in the codebase, which I guess makes sense because I submitted about 680K LOC (note: not all hand-authored, there was a lot of output from automated tools in that) and 2^15 is 32768, so I'd expect to have about 20 lines left, which is actually surprisingly close to accurate (I didn't precisely count, but a quick glance at what I recognized suggested about 200 non-deprecated lines remain in prod). It is not at all the code that I thought would still be there 15 years later, or that I was most proud of. The most durable change appears to be renaming some attributes in a custom templating language that is now deeply embedded in the Search stack, as well as some C++ code that handles how various search options are selected and persisted between queries.

I think this both proves and disproves the original point. Most of your code is temporary. You have no idea which parts of your code is temporary. It's probably not the parts that you wish were temporary, which will almost certainly be made permanent.

Good code is easy to replace and bad code is hard to replace, so bad code is disproportionately long-lived.

In my experience the code will, but by year 5 nobody is left who worked on it from inception, and by year 10 nobody knows anybody who did, and during that time it reaches a stage where nobody will ever feel any sense of ownership or care about the code in its entirety again.

I come into work and work on a 20 year old codebase every day, working on slowly modernizing it while preserving the good parts. In my experience, and I've been experimenting with both a lot, LLM-based tools are far worse at this than they are at starting new greenfield projects.

This conversation shows how diverse the field is!

When it comes to professional development, I've almost never worked on a codebase less than 10 years old, and it was always [either silently or overtly] understood that the software we are writing is a project that's going to effectively live forever. Or at least until the company is no longer recognizable from what it is today. It just seems wild and unbelievable to me, to go to work at a company and know that your code is going to be compiled, sent off to customers, and then nobody is ever going to touch it again. Where the product is so throwaway that you're going to work on it for about a year and then start another greenfield codebase. Yet there are companies that operate that way!

It's important to know which type of repo/project you are in and hire/code accordingly.

I've seen mismatch in each direction..

How can you possibly know which type of repo you're in ahead of time? My experience is that "temporary" code frequently becomes permanent and I've also been on the other side of those decisions 40 years later.

Unless you’re producing demos for sales presentation (internally or externally), it’s always worth it to produce something good. Bad code will quickly slow you down and it will be a never ending parade of bug tickets.

indeed, being on-call cleanses many developers of slopulist habits

That depends on how quick the feedback loop is for your decisions. If it takes weeks or months to find the impact of your changes, or worse, if you're insulated somehow from those changes, you may not be pushed toward improving the quality of your code.

A company where it takes weeks and months to deploy a code change is not a company with a long term success horizon.

Lolololol, sorry, I can't help but laugh a bit because some of the most entrenched companies are also the slowest moving.

It depends on their sleep habit, work-life requirements and compensation when they need to be on-call.

When you get a fatter check because your code break, the incentives are not in favor of good code.

Demos might ne nice an flashy. But eventually you actually have to have generally working product. Too many issues with too many annoyances and eventually users of even enterprise software will be heard. Especially so if there is some actual loss of money or data that is not corrected very fast.

In the end software is means to the end. And if you do not get to end because software is crap it will be replaced, hopefully by someone else.

The argument is “it’s not crap if it works and does what it’s supposed to do relatively well, and it doesn’t matter how it’s written under the hood”.

If a product looks pretty and seems to work great at first experience, but is really an unmaintainable mess under the hood, has an unvetted dependency graph, has a poorly thought through architecture that no one understands, perhaps is unsustainable due to a flawed business model, etc., to me it simply suffers from bad design[0], which will be felt sooner or later. If I know this—which is, admittedly, sometimes hard to know (especially in case of software products compared to physical artifacts)—I would, given alternatives, make the choice to not be a customer.

In other words, I would, when possible, absolutely make a purchasing decision based on how good the code is (or based on how good I estimate the code to be), among other things.

[0] The concept of design is often misunderstood. First, obviously, when it’s classified as “how the thing looks”; then, perhaps less obviously, when it’s classified as “how the thing works”. A classification I am arriving at is, roughly, “how the thing works over time”.

> The longer your product exists the more important the quality of the code will be

From working on many many old and important code bases, the code quality is absolutely trash.

And yet somehow the shittiest buggiest software ends up being the most popular.

Look through the list of top apps in mobile app stores, most used desktop apps, websites, SaaS, and all other popular/profitable software in general and tell me where you see users rewarding quality over features and speed of execution.

I don’t think this search will really reveal speed of execution and feature set rewarded over quality either.

You have it backwards. Excellent software becomes popular, and then becomes enshittified later once it already has users. Often there is a monopoly/network effect that allows them to degrade the quality of their software once they already have users, because the value in their offering becomes tied to how many people are using it, so even a technically superior newcomer won't be able to displace it (eg. Youtube is dogshit now but all of the content creators are there, and all of the viewers are there, so content creators won't create content for a better platform with no viewers and viewers won't visit a better platform with no content).

If your goal is to break into the market with software that is dogshit from day 1, you're just going to be ones of millions of people failing their get-rich-quick scheme.

Have you read the source for those products?

That is easy. Those top apps in mobile stores are constructed in part with compilers which are under great pressure from developers to generate good code as quickly as possible. There is often bloat at the level of the development environment or some critical library, but core developer tools are a big part of the software space and are made and sold with very different criteria from the most popular apps vended from walled gardens.

>> No one has ever made a purchasing decision based on how good your code is.

> absolutely false.

Actually, you are both correct.

Nobody makes a purchasing decision based on code quality.

But they may later regret a purchasing decision based on code quality.

The history of technology is filled with examples where between two competing analogous products, the inferior always wins. It does not matter if it is only slightly inferior or extraordinarily inferior, both win out. It's often difficult to come up with counter-examples. Why is this? Economic pressure. "Inferior" costs less. Sometimes the savings are passed on to the customer... they choose the inferior. Other times the greedy corporate types keep all of it (and win simply because they outmarket the competitor). It does not matter.

If there are people who, on principle, demand the superior product then those people simply aren't numerous enough to matter in the long run. I might be one of those people myself, I think.

> obviously created by people the care deeply about the quality of the product they produce

This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.

> There is no substitute for high quality work.

You're right because there really isn't a consistent definition of what "high quality" software work looks like.

> This obviously doesn't represent all of the billions of dollars spent on software like Salesforce, SAP, Realpage, Booking.com, etc. etc. (all notoriously buggy, slow, and complex software). You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product. They get real nice paychecks, benefits and put dinner on the table for their families. That's the market.

Those first three are "enterprise" or B2B applications, where the person buying the software is almost never one of the people actually using the software. This disconnect means that the person making the buying decision cannot meaningfully judge the quality of any given piece of software they are evaluating beyond a surface level (where slick demos can paper over huge quality issues) since they do not know how it is actually used or what problems the actual users regularly encounter.

Have you seen large consumer products’ codebases?… Companies like Google are tiniest exceptions when it comes to code gatekeeping and quality.

Funny how the biggest, most profitable software companies emphasize code quality.

Have you seen Facebook's code quality? Have you seen any-big Chinese corpo code? There are a lot of very profitable businesses in the world with endless amount of tech debt. But tech debt is not necessarily a big deal in most scenarios. Obviously I'm not talking about mission critical software, but for general consumer/business software, it's fine. The hard part is understanding where you can cut the costs / add debt, and that comes from requirement gathering.

At Microsoft this totally depends on the org and team. I've seen the full spectrum of quality here.

I'm pretty sure that Google is an advertising company that just happens to write software.

Riot Games around 2014(?) had the most profitable (non-mobile?) game in the world with an infamously horrific codebase, even by game standards.

Which might be true, but is totally irrelevant to the OP's comment.

Users care about quality, even if the people buying the software do not. You can't just say "well the market doesn't care about quality" when the market incentives are broken for a paricular type of software. When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software (see Windows in the consumer OS market, which is perceptibly losing share to MacOS and Linux following a sustained decline in quality over the last several years).

> "well the market doesn't care about quality"

You literally just told me the market doesn't care about quality. I don't get what point you're trying to make?

> When the market incentives are aligned between users and purchasers (such as when they are the same person) quality tends to become very important for the market viability of software

Right, but this magical market you're talking about doesn't exist. That's my point.

SAP, Salesforce, Booking.com… all awful products. We use them because monopolies.

I couldn't book travel at a previous company because my address included a `.`, which passed their validation. Awful, awful software. I wouldn't expect slop code to improve it.

> You can't tell me with a straight face that all of the thousands of developers who develop these products/services care deeply about the quality of the product.

What about caring and being depressed because quality comes from systems rather than (just) individuals?

Now imagine how much they would make if their software was good.

Google, Facebook, Apple clearly care deeply about the quality of their code. They have to because bugs, bad performance, outages, vulnerabilities have very direct and immediate costs for them. I know Amazon and Microsoft have their critics but I bet they are also better than we give them credit for.

There are factors besides software quality that affect their success. But running bad software certainly isn’t going to help.

> Google, Facebook, Apple clearly care deeply about the quality of their code

Not the impression I get these days.

>Google, Facebook, Apple clearly care deeply about the quality of their code. Yea, idk about that one. They definitely did care in the past. They had to if they wanted to get users. But they've stopped caring a good while ago. Especially Microsoft. The costs that bad code would bring them is lower than the cost of developping good code, because they can mostly rely on monopolies and anti-competitive practices for user retention. Their users are more like hostages than anything else.

Is Google much better? I don't see, for example, the care that used to go into the quality of organic search results.

They seem fine with the output of the current hodge-podge of the original algorithm results plus massaging by many downstream ML pipelines that run one after the other without context of how each stop might affect the next.

> You're right because there really isn't a consistent definition of what "high quality" software work looks like.

And if you can deterministically define "high quality software" with linters, analysers etc - then an AI Agent can also create high quality software within those limits.

ding. ding.

If code is craft and minimalism is hip then why ruby, and python, and go and... when it's electrical state in machines?

That's the minimalism that's been lost.

That's why I find the group 2 arguments disingenuous. Emotional appeal to conservatism, which conveniently also props up their career.

Why all those parsers and package systems when what's really needed is dials min-max geometric functions from grand theft auto geometry to tax returns?

Optimization can be (and will be) engineered into the machine through power regulation.

There's way too many appeals to nostalgia emanating from the high tech crowd. Laundering economic anxiety through appeals to conservatism.

Give me an etch a sketch to shape the geometry of. Not another syntax art parser.

Garbage software that is slow as a dog has been winning. While we’ve been obsessing over our craft and arguing about what makes software beautiful, slow crappy software has taken over the world.

Quality of code is just not that important of a concept anymore for the average web developer building some saas tool. React code was always crap anyways. Unless you are building critical systems like software that powers a plane or medical equipment, then code quality just doesn’t really matter so much in the age of AI. That may be a hard pill to swallow for some.

> then code quality just doesn’t really matter so much in the age of AI

Except at scale it really does, because garbage in garbage out. The crappier the code you feed the current models, the worse and more confusing the broken leaky abstractions, the more bugs the AI will generate.

There's a lot of space between web dev and medical equipment. I've never met a user that loved how often their work was lost or how long it took to implement feature requests amid all the ship-it-quick duct tape.

The question is whether it has to be that way. Developers who are against slop don’t believe that the current state of software is the best possible world.

I believe a lot if large software companies like Google, Facebook, Apple, Netflix, Microsoft have very high quality code. Past a certain level of complexity, bad code will just collapse under the weight of its low quality.

I think you can scrap Microsoft there when it comes to their pc stuff and their mainly B2B stuff (dynamics and the like) As for the rest other than apple I think pageloads are an obvious metric to track and there's always going to be a contingent of their programmers incentivized to care about their code quality because slow code and the like runs on their machines at such scale that it often costs them a lot of money, same with uptimes of various services. Their amount spent on wages is comparatively very low.

> Past a certain level of executions

I don't think complexity is the right metric. The listed companies still do write a lot of shit software, but mostly smaller things you don't see much. Anything in the 'fast path' of these companies is getting executed trillions or quadrillions of times and because of that any bugs will become shallow.

I treat the code I produce as my craft and I appreciate I can afford it and enjoy the output.

I know engineers who aren't that lucky and struggle in "enterprise" software development, where slop was a feature for decades - people making decisions won't use the software (their low paid employees will) and software monstrosities need a hell a lot of support which sometimes brings more revenue than the original purchase.

There's a big gap though between bug free, performance, etc and craft

> People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work quickly

The assumption that people CARE about your product is the most Silicon Valley, Hacker News, forgot what the world out side of tech looks like thing ever.

People CARE about their software as much as the CARE about their bank, or a new finance product... People excited over software is more of a historic footnote than any thing real people think in 2026.

The vast majority of Software is one of two things:

A) a tool

B) a source of entertainment

As a tool it either needs to provide value or it's something that is shoved on you by work.

The user experience of your average mobile game today is fucking awful. People put up with a massive amount of garbage for a trickle of fun. So much of the web looks like a mid 90's Hong Kong back alleyway --- biking ads, videos screaming at you, and someone trying to steal your wallet. And the majority of things people are forced to use for work... well... Show me someone who is excited about their ERP or CMS or Network drive... Show me someone who thinks that anything to do with Salesforce is something to be excited over.

> The general public does not care about anything other than the capabilities and limitations of your product.

A segment of our industry is screaming about the security of open claw. People dont care (because we have also made a mockery of security as well) - they are using it as a tool that will deliver them a solution. It strips away all the arcanea that made people think we were wizards and writes the dam spells for them. It's a dumpster fire, and people are thrilled about it and what its delivering them. And thats software not made by you or I.

> People dont care (because we have also made a mockery of security as well) -

They will start caring when a security bug on one of their phone's apps (or on the phone's software itself) empties their savings accounts. At that point the law officials/the Government might also start to care.

UHHH...

Mt. Gox, FTX, and an ocean of crypto wallet exploits.

This has already happened, and unlike traditional banks, there is no "customer service" to call with a shot at reversing a transaction.

It already happens to regular businesses, and on a regular basis: from credit card skimmers to major hacks, Home Depot springs to mind, along with numerous other ones that just dont even warrant the attention.

Meanwhile, yet another supply chain attack yesterday.

Security exists in most companies to protect management and give them a head to hang when the shit hits the fan (not IF, when). It's a cost center and is getting butchered right now in many orgs (we haven't had a problem why bother).

I would add to that for software that has scaled to the point that it needs to run in a distributed fashion, code quality will show up very quickly in dollars and sense.

High latencies, outages, memory leaks, security vulnerabilities, will be seen in your AWS bill or whatever hardware or service you deploy your software to. If your code isn’t clear enough to understand what it’s really doing, you have no chance at preventing or addressing the above.

> There is no substitute for high quality work.

Have you taken a look at the world in the past… I dunno, at least several decades. That ceased to be true somewhere around the time I was in high school, maybe before.

You're responding quite harshly to a pretty reasonable take. I think he means "for the most part" for those statements.

I mean Jira is probably one of the most purchased software packages in the world that is specifically used by developers that care about their craft - you don't want to look at the code, trust me.

> There is no substitute for high quality work.

That's where you get it wrong. The world is full of mediocre and low quality work in many, many fields. We all, in fact, depend on mediocre work in many ways.

Many, many people would prefer a solution with mediocre or even bad code than no solution at all while they wait for "high quality work" that never appears.

The magic of LLMs, especially as the technolgy improves, is that a truly mind boggling number of solutions to problems will be created with thoroughly mediocre (or worse!) LLM generated code. And the people benefitting from those solutions won't care! They'll be happy their problems are being solved.

No, you see, this is impossible, as I've been taught here on HN by the wise elders over and over. As soon as a pristine codebase is tainted by even 1% of LLM-generated code, any chance at potential user value instantly disintegrates. Especially if it claims to do anything remotely novel!

But seriously, the denial is incredible to watch. Our product wouldn't exist without LLMs, and our users are vocally thankful that it does, saving them time and money and helping them reach their offline goals.

[0] https://news.ycombinator.com/item?id=47505428

[1] https://news.ycombinator.com/item?id=47476893

Among countless others

> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.

For now. We only call it slop when we notice it. Majority of AI text, music, images, videos and code is indistinguishable and you use it every day.

This whole "treat your code as craft" reminds me of organic farming, zero waste, etc movements. Cute movements that only minority of people care about.

> Majority of AI text, music, images, videos and code is indistinguishable and you use it every day.

I really don't think this is true. If it was, we'd be able to point to countless examples of things assumed not to be AI that actually were, but there's a dearth of such examples.

Examples _are_ countless. Look around yourself - it's simply indistinguishable. Videos are still not quite there, the biggest telltale is how short they are, but we are very very close.

> Examples are countless

Then you should be able to name at least one.

Is it really? I disagree strongly on all points, but know where you are coming from by an intuitive sense. I am a dev since the 80th and know how to make 64kb do wonders. It just took us years to find out.

You present no proof only touchy feely it must be so otherwise pseudo proof like software longevity is on the line.

Please first define software longevity quality in detailed terms: what is it exactly and how to you assess it regarsing quality and quantity?

Doom is judged by myself and by its versatility a masterpiece however, we all know and the Black Book is quite open about it the code itself is arguably not hitting modern standards as of today and there is a infamous WTF hardcoded value used to do speed code. So what? It inspired a whole generation. Second reality? A mindbender demo that accelerated quite a few finish developer careers has sadly forgotten after it was once considered for decades to be for the demo scene on PC what Doom was for the underground gamer scene. A nice match anyway.

Is Windows a masterpiece or not? Judging by its UX/UI definitely not, by its versatility and transposable potential I would rate it a masterpiece.

1000th of developers work on some code basis which change chipsets and compiler settings quite significantly - so there are ups and downs even in domains where a simple deadline and a requirement change suddenly makes technological prowess useless trash.

And the most heretical question ever: what if your so called number one quality software product might fool you and - could be way better done? You didn’t even consider that option which makes your point shaky to say the least.

Thank you for putting out a clear message. I completely agree.

> parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks.

and of course, this isn't even the worst. A lot worse can happen, such as data loss and corruption. Things that can directly affect people's lives in real life.

As a developer, these things are constantly on my mind, and I believe this is the case for people who do care about the quality.

As has been said elsewhere many times, AI producing code is not the same as say, a compiler producing machine code. It is not such a well-defined strong abstraction, hence why code quality still is highly relevant.

It is also easily forgotten that code is as much a social construct (e.g. things that have to be done in certain ways due to real life restrictions, that you wouldn't have to do in an ideal world).

Sometimes I feel very powerless though. It feels as if some of us are talking past each other, even if we seemingly are using the same words like "quality". Or in a way, that is what makes this more futile-- that we are using the same words and hence seemingly talking about the same thing, when we are referring to completely different things.

It is difficult to have a conversation about a problem when some of us don't even see it as a problem to begin with-- until it reaches a point when it starts affecting their lives as well, whether it be directly or indirectly. But that takes time.

Time will tell.

It is a spectrum and the perspectives of people change based on where they are on the spectrum. It is genuinely hard to keep up with things and also keep my emotions in check to stay objective

This is provable false. First in B2B software the user is not the buyer. The reasons the buyer buys software is usually big because how well it performs but for a lot of other reasons.

Second, shitty electron apps are pervasive.