Live data from Hacker News

Slop is not necessarily the future

greptile.com

451–460 of 512 posts

Re: Slop is not necessarily the future

#451
Maybe not necessarily, but it'll be difficult to avoid. We're in a period where people are constantly creating and constantly changing software. Such rapid change really precludes the possibility of excellent. Very few people want to say "let's not add features, it would conflict with our ability to maintain quality." It's not that no one does this, but it is something that's in the minority.

All the change and shuffle feels like an inevitable consequence of so much communication and competition between companies, and cultures and such. Gone are the days where a software product can remain stagnant. Someone else will build something that does a bit more, or if nothing else, does something new, and it will take people's attention away.

Everyone is stuck trying to keep up with trends, even if those trends don't make any sense.

Re: Slop is not necessarily the future

#452
post #181
post #84

Earlier quoted context omitted.

> No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. 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 qu…

> 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 q…

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

Re: Slop is not necessarily the future

#453

Earlier quoted context omitted.

I'm in camp 1 too. I've maintained projects developed with that mindset. It's fine! Your job is to make the thing work, not take on its quality as part of your personal identity. If it's harder to work with, it's harder to work with, it's not the end of the world. At least it exists, which it probably wouldn't have if developed with "camp 2" tendencies. I think camp 2 would rather see one beautiful thing than ten use…

I think camp 1 would rather see ten useless things than one useful thing.

Customer pays me to make it work, not make a pretty thing that doesn't work and is over budget - but pretty.

I optimise for "make it work", that's what the deal says.

If there's extra time, I might go to step two which is "make it pretty". Meaning that I go through the code and see that it's all good and proper if we need to add features later on.

Re: Slop is not necessarily the future

#454

Earlier quoted context omitted.

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.

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

Re: Slop is not necessarily the future

#455
post #430

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

This is an often repeated reductionist classification, which I've yet to match with my real life experience. Vibe coding will fill in more "new feature" checkboxes, faster, but the level of quality averages out, to something often mediocre, or worse (like all my OSS projects in which I experiment; because such projects are the training data). It skips liberally on maintainability, accessibility, security and privacy…

Sometimes a mediocre solution is better than no solution, especially if the mediocre solution is done in days.

Yes, there are risks (Lethal Trifecta and all that), but AI assisted developmet by non-programmers isn't that much worse than letting the same people do complex macro/function/VBA setups in shared Excel sheets.

I'm running out of fingers on my hands on the number of 100% vibe-coded applications we've built internally that save double digits of % of time from people's day to day work. All created by the people who use them to fix a very specific workflow they've had to do by hand over hours. Now It's a click of a button on a bespoke application they made.

Re: Slop is not necessarily the future

#456

Earlier quoted context omitted.

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 p…

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.

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

Re: Slop is not necessarily the future

#457

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

> No one has ever made a purchasing decision based on how good your code is. As stated by others, this is very false. Most if not all software I use is selected by its disk/memory footprint and performance. Having a small disk/memory footprint and having good performance at the same time is a good indicator of a good code quality. Moreover, after using computers for more than three decades, you get a feeling about th…

I've built dozens of services and applications for companies.

ZERO times has anyone even mentioned disk/memory footprint. Performance maaybe, but no hard limits were defined in any contracts. And even those were "these things have to be processed within 24 hours because the law says so", not microsecond precision.

Even Obsidian is 440MB. It's a markdown editor with a built-in javascript scripting system. There's no reason for it to be almost half a gigabyte. Zero people have checked the directory size and went "nah, too big, won't use it".

Re: Slop is not necessarily the future

#458
post #370

Earlier quoted context omitted.

How do you even converge on the right data model without refining code? Elegant code and elegant data model are the exact same thing!

"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious." Lots of people try to make their code better by revising their procedures and don't even think about changing their data model, and generally fail. You might not be able to change your data model without changing your code, but they're differen…

Or not using the data model properly, zero foreign keys in databases, no triggers checking column contents etc.

"We'll do it on the app level".

sigh

Re: Slop is not necessarily the future

#459
post #407

I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…

> No one has ever made a purchasing decision based on how good your code is. But many ppl will refuse a purchasing because the product breaks randomly

I've used programs for 30 years. They have broke down randomly, despite being artisanally programmed by actual humans.

Being created by a human doesn't imbue any specific amount of reliability to a piece of software.

Re: Slop is not necessarily the future

#460

Earlier quoted context omitted.

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.
Post reply on HN