Live data from Hacker News

Slop is not necessarily the future

greptile.com

151–160 of 512 posts

Re: Slop is not necessarily the future

#151

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

Because the ones that sell crappy code don’t sell to people that can tell the difference.

You think I’d pay for Jira or Confluence if it wasn’t foisted upon me by a manager that has got it in with the Atlassian sales rep?

I don’t even need to see Atlassian’s source code to know it’s sh*t.

Re: Slop is not necessarily the future

#152

Earlier quoted context omitted.

The public doesn't care about the code itself, they absolutely care about the quality and experience of using the software. But you can have an extremely well designed product that functions flawlessly from the perspective of the user, but under the hood it's all spaghetti code. My point was that consuming software as a user of the product can be quite different from the experience of writing that software. Facebook…

There are other players in the game: the business and the market. Good code makes it easier for the business to move fast and stay ahead of the competition while reducing expenses for doing so.

That's true, but excel '98 would still cover probably 80% of users use cases.

A lot, and I mean a lot, of software work is trying to justify existence by constantly playing and toying with a product that worked for for everyone in version 1.0, whether it be to justify a job or justify charging customers $$ per month to "keep current".

Re: Slop is not necessarily the future

#153
“John Ousterhout [..] argues that good code is:

- Simple and easy to understand

- Easy to modify”

In my career at fast-moving startups (scaling seed to series C), I’ve come to the same conclusion:

> Simple is robust

I’m sure my former teams were sick of me saying it, but I’ve found myself repeating this mantra to the LLMs.

Agentic tools will happily build anything you want, the key is knowing what you want!

Re: Slop is not necessarily the future

#154
post #117

Earlier quoted context omitted.

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

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.

Re: Slop is not necessarily the future

#155
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…

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

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.

Re: Slop is not necessarily the future

#156
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…

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

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

Re: Slop is not necessarily the future

#157

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…

3. Coding is fun, prompting not so much

Re: Slop is not necessarily the future

#158
post #18

Earlier quoted context omitted.

> What if we built things that are meant to last? Would the world be better for it? You'd have a better bridge, at the expense of other things, like hospitals or roads. If people choose good-enough bridges, that shows there is something else they value more.

Once the good-enough bridge deteriorates and we have to spend more money maintaining or replacing it Don't we end up just spending the same? Just now we're left with a crappy bridge.

It might very well be that building and maintaining a bridge for 100 years costs three or four times as much as building and maintaining one that last 50 years. If demolition costs are not same as cost of bridge well in long run replacing the bridge ever 50 years is cheaper.

On whole it is entirely reasonable optimisation problem. What is the best lifespan of single bridge over desired total lifespan.

Re: Slop is not necessarily the future

#159

Earlier quoted context omitted.

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

It's important to know which type of repo/project you are in and hire/code accordingly. I've seen mismatch in each direction..

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.

Re: Slop is not necessarily the future

#160

Earlier quoted context omitted.

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

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