I have lived through several waves of technology and change that would supposedly make me obsolete as a programmer and system admin. Over forty years in the business now, I have learned to take those predictions with a lot of skepticism.
If LLMs get close to doing any part of my work I will incorporate them, like I have previous “threats” like cloud computing. I won’t panic too soon or give up because I have enough experience and expertise to know better.
I can't predict what might happen, but right now LLMs don't do much of value in the domains I work in. They seem mainly to exist as excuses for stock pumping and managers cutting their labor costs to the bone. The people who don't get laid off cling to their jobs out of fear. The threat to (mostly junior) programmers comes from turning our work into a commodity, not from automation itself.
Maybe your analogy does apply. A person who can drive a tractor will indeed outperform a farmer in one important but limited way: covering more area in a day than a farmer on foot. But the person who can only drive a tractor likely won't have all of the skills and expertise of a farmer who knows the land, soil, crops, weather, etc. from direct experience. And the person who can only drive a tractor -- but cannot actually grow anything or manage a farm -- becomes more interchangeable and replaceable. Tractor driving already gets replaced by robots, but knowing how to run a farm does not. Likewise a good programmer offers a lot more value than just the code they write; in fact code itself has no value without the context of a business domain and a theory [1] of the system.
By the way, I'm one of those old guys who still use vim and the command line, as I have since the late 1970s, and will continue to do so. I can use IDEs and GUIs if I have to, I didn't get left behind, but those don't improve my efficiency or quality. They can slow me down and distract me with futzing with tools rather than getting real work done, and they don't work in all of the environments I need them to. I haven't had any problem keeping up with the IDE users.
old as well, in the industry since 1996… I get what you are saying but I can honestly tell you I have spent last 6-ish months analyzing these tools and making comparison between vim and IDE vs. someone (not) using LLMs is not even remotely reasonable comparison…
given your age/time in the industry you may be able to coast to retirement and finish the career and say “vim got me through it all…” - someone with 10-years in will never be able to experience that
I have played with LLMs (and many IDEs). I won't say they suck, but they don't give me any huge boost either. Other programmers may get more mileage out of them, but so far no one I have worked with reports any difference that seems more significant than novelty. We all feel more "productive" when we challenge ourselves to learn a new language, tool, programming technique, platform, etc. When that wears off we have to find the next shiny thing. LLMs have the added feature of FOMO and actual fear of unemployment that, for example, VSCode did not have.
All tools take time to master, and then once mastered they can maintain an advantage over competitors that seem objectively better in some ways. I used VSCode for a year and ended up going back to vim. Nothing really wrong with VSCode but it wasn't a 10X or even 2X improvement for me. But I have internalized vim and the Unix/Linux command line tools to a degree that -- as you point out -- younger programmers don't have the runway to catch up with.
As a freelancer (and for a long time a f/t employee in various companies) I gradually figured out that the best value I can offer (and the best way to stay employed) is not how fast I can produce code, but how well I can understand the business domain and then tease out and translate requirements into software solutions. Optimizing for producing more or "better" code (however we measure that) I think sends a lot of programmers down the wrong path, one that leads to over-specialization, commodification of skills, and eventual replacement by outsourcing or AI. I think it will take a lot longer for LLMs to do the real work of software development, which has about as much to do with producing code as word processing has to do with writing an interesting book.
If LLMs get close to doing any part of my work I will incorporate them, like I have previous “threats” like cloud computing. I won’t panic too soon or give up because I have enough experience and expertise to know better.
I can't predict what might happen, but right now LLMs don't do much of value in the domains I work in. They seem mainly to exist as excuses for stock pumping and managers cutting their labor costs to the bone. The people who don't get laid off cling to their jobs out of fear. The threat to (mostly junior) programmers comes from turning our work into a commodity, not from automation itself.
Maybe your analogy does apply. A person who can drive a tractor will indeed outperform a farmer in one important but limited way: covering more area in a day than a farmer on foot. But the person who can only drive a tractor likely won't have all of the skills and expertise of a farmer who knows the land, soil, crops, weather, etc. from direct experience. And the person who can only drive a tractor -- but cannot actually grow anything or manage a farm -- becomes more interchangeable and replaceable. Tractor driving already gets replaced by robots, but knowing how to run a farm does not. Likewise a good programmer offers a lot more value than just the code they write; in fact code itself has no value without the context of a business domain and a theory [1] of the system.
By the way, I'm one of those old guys who still use vim and the command line, as I have since the late 1970s, and will continue to do so. I can use IDEs and GUIs if I have to, I didn't get left behind, but those don't improve my efficiency or quality. They can slow me down and distract me with futzing with tools rather than getting real work done, and they don't work in all of the environments I need them to. I haven't had any problem keeping up with the IDE users.
[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf