← Back to context

Comment by jdw64

9 hours ago

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.