Live data from Hacker News

Slop is not necessarily the future

greptile.com

401–410 of 512 posts

Re: Slop is not necessarily the future

#401

“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!

Yes. Which is why "I generated X lines of code" "I used a billion tokens this month" sound stupid to me. Like I used 100 gallons of petrol this month and 10 kilos of rabbit feed!

The same people that pursue economic incentives are who I hear speaking about number of lines produced by developers as a useful metric. I sense a worrying trend toward more is better with respect to output, when the north star IMHO should be to make something only as complex as necessary, but as simple as possible. The best code is no code at all.

Re: Slop is not necessarily the future

#402
post #399

Earlier quoted context omitted.

It also went real fast from "GPT hallucinated a library, literally useless" to "this agent has created this entire service up to spec, no notes".

It seems that we are getting bitten by the law that says things that can be measured trumps things that cannot be. How fast it was to create an initial version of a piece of software can be easily measured. But how efficient it is, how easy it is to make changes to it, how easy it is to debug it, how easy it is to extend in the direction that the domain requires...all these cannot be easily measured or quantified, bu…

I said nothing about speed, I said to spec. Speed is a welcome side effect.

Re: Slop is not necessarily the future

#403

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 the performance of a particular software suite. So an inefficient piece of code makes itself known in a loud way if you look the right way.

One of my favorite applications, Obsidian, is generally performs well, but when you hit it just the right way (e.g. add a couple of PDFs and enable previewing), you can feel how sluggish it becomes.

Having a suite of well written applications which have high performance/footprint ratio also allows me to do more with less resources and in less time. So, good code quality matters. It also almost guarantees the software suite will be maintained in a longer time.

Incidentally, I'm also in camp #2, and write my code with the same attention to detail. I have also written code which squeezed all performance from systems, approaching theoretical IPC limits of the processor the code is running on.

Re: Slop is not necessarily the future

#404
post #84

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

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.

Re: Slop is not necessarily the future

#405

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…

I fall strictly into camp 1, but I disagree on code quality.

Code quality makes the difference between a janky system that works most of the time and a rock solid system that is an enjoyment to use.

QA can only apply duct tape. If your state management isn’t clean, the UX will suck. If your functions aren’t clean, you will keep chasing bugs.

Luckily, AI is capable of writing good code. Today, that still requires some amount of hand holding, but it’s getting better.

Re: Slop is not necessarily the future

#406
post #84

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

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

Re: Slop is not necessarily the future

#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

Re: Slop is not necessarily the future

#408

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…

There's not that much about art and craft but about knowing that less is more and that adding complexity to a thing (almost any thing) will only bring greater troubles down the road. We've had to learn this as an industry for how long now?, I'd say 70 years, give or take (I've only been a professional programmer for about 20 years, if that counts), so a new methodology coming in and saying that there is indeed a silver bullet might not be that well-received.

Re: Slop is not necessarily the future

#409

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 to determine good code, you need to see it and I'd presume most open source code is free.

Re: Slop is not necessarily the future

#410
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 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 abo…

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

Post reply on HN