I've also been doing this professionally for about 30 years, plus another 10 as a hobby/learning before then, so I think I have much of the same experience as you, and I do agree. Although, I think with the advent of LLMs, programming is no longer the hard part. The hard part of programming is the convergence of context management for humans while also presenting it to a computer to do something. Much of data structures and algorithms "best practices" are ways to efficiently get your work done as well as keeping it so that a human has context.

For example, one guy I used to work with wrote this really awesome algorithm about 25 years ago, and I'm responsible for maintaining it since he long retired. I can't go into details, but this is the core algorithm in moving billions of dollars between institutions overnight. It's about 10 screenfuls of c that had been converted from the original FORTRAN 77 with dozens of gotos and weird branching statements and about 20 parallel arrays that store indices for pointer chasing. It's almost impossible for a human to follow (I've actually fed it to an LLM and said rewrite this with for loops and no gotos so I can understand it - and it worked!) but it's blindingly fast. The actual problem it solves can be stated in about three sentences, but programming it was hard because of the context management. The reason that my company keeps getting royalties on this is that it's so hard that they'd rather pay us than write it themselves. But I bet an LLM could write it from scratch now.

So maybe programming is no longer the hard part, or at least context management is no longer the hard part and that humans should move up the chain to help manage the context for LLMs so they can get more done efficiently.

Switching topics a little...much of what I think makes coding the hard part was the tension between big-design-up-front and you're-not-going-to-need-it philosophies. Early in my career I worked in health care and that was BDUF and the coding was easy because program managers spent years defining every screen that would be shown to the users, what queries were needed to fill the screen, all of that. We just took the spec and coded it. Coding was easy. But the failure of BDUF was that it still didn't really match what the customer wanted.

Then enter agile and YAGNI, in that limit, coding is easy, just write what the user story says. But then you have to refactor from what was left behind on yesterday's user story. So smart engineers would cheat a little with YAGNI and say, yes we will put an abstraction in because the next user story. I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill. And I think that's what all the wailing and gnashing of teeth is right now: the good engineers aren't needed anymore.

I can tell an LLM to code something, and as I add complexity it's happy to refactor and manage the context so we don't need to worry about "clean code" or "quality code". As long as what the LLM writes meets the spec, then we're happy.

Ah, sorry long rant and ramble. But I just think the "hard part" has been managing context, and the context we're managing context is just changing. Those good at managing context will be good at coding with LLMs, and those that weren't won't be.

This is a very good comment, one of the best i've read here.

> I would say that "good engineers" or "good coders" found that balance in abstraction to move fast but make abstractions not overkill.

i think this is spot on and could be where the concept of "llm's have no taste" comes from. There is art (and science) in determining the right level of abstraction that satisfies the user story in a performant way while leaving the door open for extension.

> As long as what the LLM writes meets the spec, then we're happy.

going back to just meeting the spec vs the art of perfect abstraction is a bitter pill to swallow and I imagine removes a lot of the joy some found in software development.