[TheCleric]

This is so good and almost exactly expresses my own thoughts. There's a narrow window where it's capable and fits a need of tedious work (mostly around automating tasks it would take me a bit to remember all the arguments and commands I'd have to chain together to do it). But a lot of it is the stuff I actually WANT to be doing. And solving the hard problems makes me a better developer just as training in the gym makes your body stronger.

[thangalin]

I have the opposite experience:

* https://repo.autonoma.ca/repo/treetrek/tree/HEAD/render/rule... - syntax highlighting for 40 languages and file formats in ~10 minutes

* https://shufflenblues.com/expenses/ - real-time expenses progress updates with payment vendor API in ~30 minutes

* https://repo.autonoma.ca/repo/treetrek/tree/HEAD/git - real-time, cache-free raw Git reader implementation with cloning in ~5 days

* https://repo.autonoma.ca/repo/notanexus - PDFjs integration in ~3 days

However, these are likely not the "hard" problems you've mentioned. I feel like I can architect solutions at a higher-level now, without having to be completely caught up in many technical nuances. I'd rather not learn the extensive PDFjs API, for example, because it would take weeks of effort to understand.

[f311a]

Why reinvent the wheel? Syntax highlighting, git. I'm pretty sure there are PHP libraries to do that.

Your syntax highlighting is very basic as well. Just ask LLMs to provide tests where it would fail to render correctly.

The first thing that comes to mind after looking at it: print("# not a comment")

[thangalin]

> Why reinvent the wheel?

Dependency-free, performance, FORTRAN, and it would take me more than ten minutes to find and integrate a highlighter that works across all of my code bases.

I searched for PHP-based Git libraries. All of them either invoked "git" using a system call or offered write abilities to the repo. I wanted a pure PHP solution that did not write to any files or invoke executable files (for security purposes). Maybe I didn't search long enough; at some point it becomes faster to tell the LLM what's wanted than to find a solution that fits.

> print("# not a comment")

Works correctly?

https://i.ibb.co/chgVkTz4/not-a-comment.png

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

[avgDev]

I'm not paying someone to dig by hand if a machine makes the job quicker.

[runarberg]

In this analogy most people are already using an excavator, however some people are using an expensive driverless excavator which sometimes digs the wrong hole, and your boss is wondering why they are paying you to prompt the excavator when they know just as well as you how to prompt the machine to dig big holes.