Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slop is not necessarily the future

greptile.com

Post reply on HN
Print view View original

181–190 of 512 posts

Re: Slop is not necessarily the future

#181

Post by mbesto »

nocman wrote: post #84
seamossfet wrote: post #31

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…

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

Re: Slop is not necessarily the future

#182

Post by solid_fuel »

quantummagic wrote: post #78
seamossfet wrote: post #31

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 a very useful insight. It nicely identifies part of the reason for the stark bifurcation of opinion on AI. Unfortunately, many of the comments below it are emotional and dismissive, pointing out its explanatory limitations, rather than considering its useful, probative value.

I find most home inspectors fall into one of two camps:

1. You treat the house as a means to an end to make a living space for a person.

2. You treat the building construction itself as your craft, with the house being a vector for your craft.

The people who typically have the most negative things to say about buildings fall into camp #2 where cheap unskilled labor is streamlining a large part of what they considered their art while enabling people in group #1 to iterate on their developments faster.

Personally, I fall into the first camp.

No one has ever made a purchasing decision based on how good the pipes inside the walls are.

The general public does not care about anything other than the square footage and color of your house. Sure, if you mess up and one of the houses collapses then that'll manifest as an outcome that impacts the home owner negatively.

With that said, I do have respect for people in the latter camp. But they're generally best fit for homes where that level of craftsmanship is actually useful (think: mansions, bridges, roads, things I use, etc).

I just feel like it's hard to talk about this stuff if we're not clear on which types of construction we're talking about.

Re: Slop is not necessarily the future

#183

Post by keeda »

dcchambers wrote: post #30
simianwords wrote: post #29

People are not emotionally ready to accept that certain layers of abstraction don’t need as much care and effort if they can be automated. We are at the point where a single class can be dirty but the API of the classes should be clean. There’s no point reviewing the internals of a class anymore. I’m more or less sure that they would work as intended. Next step is that of a micro service itself. The api of that micro…

Does performance not matter? What if your AI uses an O(n) algorithm in a function when an O(log n) implementation exists? The output would still be "correct"

> Does performance not matter?

No, unfortunately. In a past life, in response to an uptime crisis, I drove a multi-quarter company-wide initiative to optimize performance and efficiency, and we still did not manage to change the company culture regarding performance.

If it does not move any metrics that execs care about, it doesn't matter.

The industry adage has been "engineer time is much more expensive than machine time," which has been used to excuse way too much bloated and non-performant code shipped to production. However, I think AI can actually change things for the better. Firstly, IME it tends to generate algorithmically efficient code by default, and generally only fails to do so if it lacks the necessary context (e.g. now knowing that an input is sorted.)

More importantly though, now engineer time is machine time. There is now very little excuse to avoid extensive refactoring to do things "the right way."

Re: Slop is not necessarily the future

#184

Post by theredsix »

seamossfet wrote: post #31

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…

With AI you actually don't need to choose anymore. Well laid out abstractions actually make AI generate code faster and more accurately. Spending the time in camp 2 to design well and then using AI like camp 1 gives you the best of both worlds.

Re: Slop is not necessarily the future

#185

Post by giancarlostoro »

seamossfet wrote: post #31

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…

> 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 on their product faster.

I'm weird, I'm part of camp 2, but I think AI can be used to really craft some interesting things. While I appreciate camp 1, camp 2 is what produces better codebases that are easier to maintain, myself and others have realized, that the best practices for humans are also the best practice for AI models to fit your code.

Re: Slop is not necessarily the future

#186

Post by Waterluvian »

seamossfet wrote: post #31

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…

It’s much more complex. Part of your value as an engineer is having a good feel for balancing the trade offs on your code.

Code is usually a liability. A means to an end. But is your code going to run for a minute, a month, a year, or longer? How often will it change? How likely are you going to have to add unforeseen features? Etc. Etc. Etc.

Re: Slop is not necessarily the future

#187

Post by ryandrake »

seamossfet wrote: post #31

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…

Trying to describe craftsmanship always brings me back to the Steve Jobs quote:

“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”

Re: Slop is not necessarily the future

#188

Post by tredre3 »

pklausler wrote: post #28
StevenWaterman wrote: post #16

Earlier quoted context omitted.

Safety factors exist because without them, bridges fall down

The free market ensures that bridges stay up, because the bridge-makers don't want to get sued by people who have died in bridge collapses.

That is definitely not the free market at play. It's legislative body at play.

Engineers (real ones, not software) face consequences when their work falls apart prematurely. Doubly so when it kills someone. They lose their job, their license, and they can never work in the field again.

That's why it's rare for buildings to collapse. But software collapsing is just another Monday. At best the software firm will get fined when they kill someone, but the ICs will never be held responsible.

Re: Slop is not necessarily the future

#189

Post by kalaksi »

reese_john wrote: post #27

Why build each new airplane with the care and precision of a Rolls-Royce? In the early 1970s, Kelly Johnson and I [Ben Rich] had dinner in Los Angeles with the great Soviet aerodynamicist Alexander Tupolev, designer of their backfire Bear bomber. 'You Americans build airplanes like a Rolex watch,' he told us. 'Knock it off the night table and it stops ticking. We build airplanes like a cheap alarm clock. But knock it…

And then everyone disagrees what counts as luxury in software.

Re: Slop is not necessarily the future

#190

Post by MrRadar »

mbesto wrote: post #181
nocman wrote: 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…

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

Post reply on HN