Live data from Hacker News

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

pluralistic.net

21–30 of 82 posts

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

#21
post #19

Earlier quoted context omitted.

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

But does what they present work for production or they present a demo and leave it to someone else to figure out how to make it work for real?

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

#22
Realistically speaking, most programs, no, 90% of them are terrible. Including mine. I write terrible code too, so I'm in no position to judge.

The programs I've taken apart and looked at, even ones running in real industrial settings and large corporate factories, 90% of them are terrible.

Most code is just 'Today's Task.' The people who deny this are probably those working at IT service companies, because they build around maintainability and scalability.

But as you go down into hardware, there's an additional pressure: 'We don't know when this hardware will reach end-of-life.' The centaur metaphor is a simplified dichotomy. 'Centaur is good, reverse-centaur is bad.' But in reality, the vast majority of programs end up as disposable one-off code.

These days, AI related articles just seem to amplify whatever values people want to believe, turning into tribal warfare posts. Realistically speaking, you can write maintainable code with AI too. In fact, the 'Canonization' mentioned in this post is essentially pattern-templating, which AI does better.

The fundamental problem with AI code is that as the input prompt gets deeper, it introduces enterprise level complexity rather than the depth the program actually needs. I don't think that's the core issue here.

The advantage of human written code is that it can be complex when it needs to be and simple when it doesn't, but AI code tries to apply the same level of complexity everywhere. Honestly, the most widely used things in the world are CRUD, and I don't think they require that much complexity.

A good programmer applies the right level of complexity to the situation.

Even human written code leaks abstractions depending on requirements.

Take ORM as an example. Can you see the query count? Is there a rule to prevent N+1? Conditions like these keep getting added. It's just a matter of explicitly adding a layer to handle them.

These days, I see a lot of AI articles filled with nostalgia about how things were different in the past, and it catches me off guard. I'm not sure if that's really how Western programming culture was, or if where I am, the vast majority of work has always been just 'get it done.'

In my opinion, good programming is about choosing the right level of complexity based on the code's expected lifespan, likelihood of change, cost of failure, and transferability. I don't think everything needs to be maintainable.

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

#24
post #21

Earlier quoted context omitted.

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

But does what they present work for production or they present a demo and leave it to someone else to figure out how to make it work for real?

Exactly what I've found. It passes the sniff test, but it's now _more work_ to get it from there to actually working.

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

#25
> the capital was raised for AI requires that it produce as many reverse centaurs as possible, because the only way to recoup the farcical sums associated with AI production is to fire millions of workers and replace them

I'm not sure that this is the only way, just the way that selfish, sloppy, or impatient actors within business often work. If more wealth is created, more efficiencies found, more problems fixed, new jobs created, these would also bring the returns desired.

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

#26

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

> It could be that this person has something profound to say

Some commentators are unknown for good reason, or otherwise not worth the effort to get to know. Cory Doctorow is not one of those.

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

#27
post #21

Earlier quoted context omitted.

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

But does what they present work for production or they present a demo and leave it to someone else to figure out how to make it work for real?

This is a running production service. The team was reduced to just these 2, per the lead's instuction.

The closest I can explain this phenomenon to thos who are surpised was by the LLM variance section in this recent blog post:

https://danluu.com/ai-coding/#llm-variance

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

#28
post #23

AI is a tool. Stop treating it as something different. The value you can extract from a tool depends on your skill in using it, and knowing when not using it.

I could write more, but I think it actually is different. The addictive nature and the way it makes you more and more dependent on it is quite different from other tools. I've never met a builder who is addicted to their circular saw.

These AI companies have stumbled upon the new cigarette. Did you know athletes in the 1920s would smoke cigarettes because they thought it improved performance? Cigarettes are just a tool, right? Of course, we could never be as stupid as they were...

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

#30

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

The real trick is recognizing when "disposable" code has quietly become infrastructure
Post reply on HN