[aogaili]

Developers were not solving hard problems. The last decade was brutal—mainly frameworks, libraries, configurations, etc. The hard problems were in research.

And regarding the gym, sure, you might enjoy lifting dumbbells and solving puzzles to sharpen your brain. But that is not what engineers are hired for; they are hired to deliver a system using the best tools available. You can choose to farm by hand while the industry moves to using tractors, but sooner or later, you will be left behind.

And lastly, moving higher in abstraction allows us to tackle even more complex problems—I'd argue much more complex than the narrow puzzles we were facing before. Part of the resistance is simply an avoidance of facing higher-level complexity once the lower tier is automated.

[wieie]

These comparison don’t capture reality at all… wish people would stop doing them.

[aogaili]

Which part of reality does it not capture?

I've been in the field for 20 years, and I do think the situation is analogous. We might not like it or we might deny it, but the fact is, LLMs do automate the mechanical part of thinking. Some people might not accept that, but that is the reality given my subjective experience and the experience of many others who are using the tool.

[suddenlybananas]

Some developers solve hard problems and some don't. It depends entirely on your specific work.

[aogaili]

Indeed. But my argument is that a lot of those hard problems were, in fact, already solved; some people made a career out of solving the same problems over and over again. The fact that we have a tool to automate the lower tier of problem-solving doesn't mean we are no longer solving problems—it just means we are being asked to solve higher-order problems.

[kaffekaka]

But it also means we solve the same problems as before but faster, meaning less time is given to planning and thinking about what to actually build. This is a real problem where I work. Everyones grasp of what we are building and how it is connected is markedly worse nowadays.

We as a collective must learn the skill to put these new abilities to good use instead of just aiming to accelerate as much as possible.

[SJMG]

Indeed, I solve hard problem for a living, but those are mostly design. The actual engineering often decomposes to gluing things together with limited need for new primitives.

There are hard problems at every level of abstraction. TAGE predictor optimization up to handling data-center failover.

I don't really have a challenge for people like the OP, I get it. I too dragged my feet, even mourned the death of a type of work I had grown fond of. Then I got over it and realized I might prefer the romance of riding a horse into town, but I also like that there's semi-trucks delivering fresh produce to my grocery store year round. The leverage available right now is frankly insane. The one thing an "old dev" [as he self-labeled] can be sure of is that the younger generations will not share these hang-ups to the same degree and it's those people who will inherit the burden of maintaining and furthering the digital world.

[aogaili]

I agree, and this matches my experience as well.

After 20 years of coding, I do understand the grief and the sense of loss—I felt it deeply myself. But as an engineer, I was also captivated by the capabilities of the new systems. Watching these systems mechanize the thinking I had been doing for years, struggle in areas I used to struggle with, and even outperform me in some areas is nothing short of a magical experience, leaving all the anxiety about the job aside. Personally, I chose to focus on that magic, to see how far we can push these tools and discover what their limits are.

[aogaili]

What is also interesting is that what our brains perceive to be hard is mainly because we didn't evolve to deal with these kinds of problems. But as it turns out, automating logical problems is much easier than folding clothes.