Live data from Hacker News

The difference between "today's task" and "accretive work"

pluralistic.net

11–20 of 82 posts

Re: The difference between "today's task" and "accretive work"

#11
post #5

Guys really pushing to remain relevant with the reverse centaurs shtick.

Since when did the distinction between use-cases stop being relevant?

There might be some relevance to the term reverse centaurs. I dont know if I buy it but it might take off as useful terminology.

A blog post loosely summarized as "HEY REMEMBER WHEN I COINED THAT TERM HERE ARE THE LINKS TO ALL THE TIMES I USED THE TERM AND HERES A NEW ANECODOTE ABOUT THE TERM" screams that its trying to force the use, and therefore the posters relevance.

Re: The difference between "today's task" and "accretive work"

#14

"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive."" Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

That quote also resonated with me. It reminded me of "Perl, the write-only language"-meme of yore.

And I think there is a place for perl, just like there is a place for bash one-liners.

The authors example is personal software. The things we write to scratch our own little itches, that do not need to be shared or developed together with other people.

Re: The difference between "today's task" and "accretive work"

#15

It could be that this person has something profound to say, but ... it's about AI. Sigh and swipe left.

I don't think it has something "profound" to say, but it also is a good article worth the read.

It's mostly about why some people enjoy working with AI ("I get to build things I can use, that I couldn't build otherwise!)" and others don't ("This code is all slop and nobody understands it, and it makes me sad")

It touches a little bit about those two perspectives in general, which he calls centaurs (in charge of the work) and reverse centaurs (the work is in charge of them)

Re: The difference between "today's task" and "accretive work"

#16
Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”?

I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two)

If one Steve Yegge can burn tokens in “Gas Town” that cost as much as me and ten others then you have saved my salary but spent it on Steve’s token use for roughly the same code quality as me steve and ten others would have produced in three months - just it took steve three days

Same price, faster delivery. Is that a win ? I suspect that facebooks recent announcement (“we cannot think of enough things to do with software so who wants our GPUs?” Might suggest that it’s a business model problem more than a software probkem

Re: The difference between "today's task" and "accretive work"

#17

"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive."" Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

>>> Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.

Fantastic

Re: The difference between "today's task" and "accretive work"

#18

Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”? I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two) If one Steve Yegge can burn tokens in “Gas Town” th…

Good analysis. Infact, there's collaboration cost in AI when it comes to quality, but a much smaller team can put out same quality things in a shorter time. As such it's same quality for cheaper, for sure.

Re: The difference between "today's task" and "accretive work"

#19

Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”? I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two) If one Steve Yegge can burn tokens in “Gas Town” th…

Good analysis. Infact, there's collaboration cost in AI when it comes to quality, but a much smaller team can put out same quality things in a shorter time. As such it's same quality for cheaper, for sure.

Can they?

What products are you talking about? Because I see smaller teams or one man bands putting out low quality prototypes, but not teams of 10 delivering a years work in a sprint.

Re: The difference between "today's task" and "accretive work"

#20
post #19

Earlier quoted context omitted.

Good analysis. Infact, there's collaboration cost in AI when it comes to quality, but a much smaller team can put out same quality things in a shorter time. As such it's same quality for cheaper, for sure.

Can they? What products are you talking about? Because I see smaller teams or one man bands putting out low quality prototypes, but not teams of 10 delivering a years work in a sprint.

I'm seeing that a tech lead is preferring to work with 1 other engineer on a large project, and they're thinking through and presenting the architecture to others. But in prior time, this project would have been the lead + 2 seniors + 4 entry to mid level engineers to do it.

Everyone else in the team is now just aware of what's happening, and understand the architecture from the meeting to review / discuss it. But implementation and rollout is fast and just by the 2 of them.

The lead told me maintaining the quality was so much easier for the 2 of them with the right AGENTS.md lines, as he didn't have to spend time fixing guiding many people to do the right thing in PR reviews.

Post reply on HN