Live data from Hacker News

Grief and the AI split

blog.lmorchard.com

371–380 of 404 posts

Re: Grief and the AI split

#371
post #367

Earlier quoted context omitted.

Maybe because it’s a non issue. I saw that those improvements are in the order of micro seconds, while the transfer time of a page is measure in 1/10 seconds or even several seconds. Even a game engine have something like 15 ms to have a frame ready (60hz).

Lots of small improvements add up - the total performance improvement is 53%. That's significant. If you're the size of Shopify that represents a huge saving in server costs and improved customer-facing latency.

> the total performance improvement is 53%. That's significant.

This percentage is meaningless on its own. It’s 4 ms shaved off a 7 ms process. You would need to time a whole flow (and I believe databases would add a lot to it, especially with network latency) and figure out how significant the performance improvement is actually. And that without considering if the code changes is not conflicting with some architectural change that is being planned.

Re: Grief and the AI split

#372
post #278

I think we should already get past pretending it's about people who just like typing words on their stupid mechanical keyboards. The real split is whether you like understanding systems and inventing new things or whether you are OK to delegate this part to someone else and are just happy to take credit for their success. With a small note that when someone else is a human, the credit can be justified if you mentored…

It's funny how "the real split" is always between the intellectually and morally superior (me) and the inferiors (them).

I've noticed that too and it's not too different from political discussions. At the end of the day, I think the split is really about different values people have, their identity, and justice.

A lot of developers' identities is tied to their ability to create quality solutions as well as having control over the means of production (for lack of a better term). An employer mandating that they start using AI more and change their quality standards is naturally going to lead to a sense of injustice about it all.

Re: Grief and the AI split

#373
post #367

Earlier quoted context omitted.

Lots of small improvements add up - the total performance improvement is 53%. That's significant. If you're the size of Shopify that represents a huge saving in server costs and improved customer-facing latency.

> the total performance improvement is 53%. That's significant. This percentage is meaningless on its own. It’s 4 ms shaved off a 7 ms process. You would need to time a whole flow (and I believe databases would add a lot to it, especially with network latency) and figure out how significant the performance improvement is actually. And that without considering if the code changes is not conflicting with some architect…

I'll take a 53% performance boost in my template language any day of the week.

Re: Grief and the AI split

#374
post #278

I think we should already get past pretending it's about people who just like typing words on their stupid mechanical keyboards. The real split is whether you like understanding systems and inventing new things or whether you are OK to delegate this part to someone else and are just happy to take credit for their success. With a small note that when someone else is a human, the credit can be justified if you mentored…

It's funny how "the real split" is always between the intellectually and morally superior (me) and the inferiors (them).

When one side of the discussion makes their ignorance a point of pride, defining themselves entirely based on what they now need not know, I believe you've inadvertently insulted yourself.

Re: Grief and the AI split

#375
post #114

I think the article misunderstands completely. "Craft" coders are chasing results too — we're just chasing results that last and that can be built upon. I've been in this game for a while, and a major goal of every single good programmer I've known has been to make themselves obsolete. Yes, I enjoyed meticulous hand crafted assembly, counting cycles and packing bits, but nobody had to talk me into using compilers. Ye…

You are repeating the same thing. You think having good maintainable good is important - more than the first camp. That does not mean you are correct. This mindset is useful only in serious reusable libraries and open source tools. Most enterprise code involves lots of exploring and fast iteration. Code quality doesn’t matter that much. No one else is going to see it. When the craft coders bring their ideology to thi…

When the code is low-quality, you can’t reason well about it, can’t reason well about what changes to apply and what their effects will be, can’t reason about what the outcome will be when making changes to the context (inputs, environment) the code is run it. Instead everything becomes an experiment on a black box or gray box, whose behavior you can’t well predict in advance.

Engineering is the task of making things behave predictably and reliably. Because software is malleable and rarely “finished”, this applies to changing software as well.

I’m pretty sure that there is more than one divide regarding AI among developers, but one of the dividing lines concerns the predictability and reason-ability of the tools and the code. AI fundamentally lacks these qualities.

Re: Grief and the AI split

#376

Earlier quoted context omitted.

This says nothing about where people find enjoyment. I like doing puzzles. I like it more than planning. At the end of the day, I'll do whatever builds the best thing, but I'll enjoy it more or less depending on what that involves.

> I like doing puzzles Meaning you like to put the pieces in, or you like to figure out where they should go? To me that’s the crux of the article.

Part of figuring out where the pieces should go is usually in trying to put them in, because you generally can’t visualize the complete solution in your mind just by looking at all the pieces and only thinking. I don’t think this is a good analogy.

Re: Grief and the AI split

#377
Sure, is there anyone nostalgic for debugging bash files by hand? Any sense of grief for writing C++ template headers, with all boilerplate? Hmm, does anyone like manually re-writing makefiles these days? I suspect the enthusiasts of coding craft will struggle to maintain their wonder after ~4h deep in any of these magical adventures, which surely involve inventing ad-hoc duct tape and novel, never-before-seen algorithms.

Re: Grief and the AI split

#378

I'm a craft lover but I like using the Ai for tedious tasks. Just today it tracked down a library conflict in a pom that from experience would have taken a day of trial and error.

I think there are far fewer developers who reject it for search tasks, like the one you describe, than those who reject it for (production-)code generation tasks.

Re: Grief and the AI split

#379
post #165

Earlier quoted context omitted.

It's increasingly clear that the LLMs leave more of a mark than authors realize when they run their writing through for a touching-up. This has been coming up a lot lately: https://news.ycombinator.com/item?id=47346449 . That's why readers end up reacting to the LLM imprints rather than the content. I don't mean to be critical because it's a good article! But I bet if you shared the version before it was "tightened u…

As I'm asking folks what bits they think are LLM imprints, they keep showing me bits that I originally wrote. It's really weird.

I hear you. This stuff is really messy and imprecise right now.

Re: Grief and the AI split

#380
> Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable.

"Writing code by hand" - more result oriented engineers became managers.

Editors - I don't believe Vim/Emacs used by both camps evenly.

Languages - in my field, most make-it-go people use Python and when large data is involved Python/Java with Hadoop. The craft-lovers prefer bespoke solutions when feasible, running it in a single box.

Version control - may be, but only after it got popularized by the GitHub.

Products - would make-it-go people ever create the 'git' in the form that made it a success?

Post reply on HN