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…
The difference between "today's task" and "accretive work"
21–30 of 82 posts
Re: The difference between "today's task" and "accretive work"
#22The 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"
#23The value you can extract from a tool depends on your skill in using it, and knowing when not using it.
Re: The difference between "today's task" and "accretive work"
#24Earlier 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?
Re: The difference between "today's task" and "accretive work"
#25I'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"
#26It could be that this person has something profound to say, but ... it's about AI. Sigh and swipe left.
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"
#27Earlier 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?
The closest I can explain this phenomenon to thos who are surpised was by the LLM variance section in this recent blog post:
Re: The difference between "today's task" and "accretive work"
#28AI 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.
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"
#29Re: 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.