@clacke oh my god the replies, no one comes out looking good lol
the inventor of uml comes in and says "I never said that" people reply with "what about Wix??? huh???"
incidentally i had a manager in 1998 that got a program called java studio that let you drag and drop java "beans" in a gui to make programs without coding, she told me we wouldn't need programmers in a few years
@Jason_Dodd We have gradually enabled software engineers to do more with less effort. Force multipliers. We don't flip switches to set machine code bits any more. We don't manually link libraries any more.
No matter how much they are derided, no-code and low-code solutions have enabled non-programmers to improve their productivity and sometimes become programmers when necessary (more seldom full-blown software engineers, but that happens too and often leads to very well-rounded and innovative software engineers). Programmable spreadsheets are the prime example.
Mostly though this has through a kind of Jevons' Paradox made human programmers even more sought for. Some tasks don't require them any more, so they have been made available for other tasks that do require expertise and an ability to translate requirements into implementation.
Seems clear to me that what's different this types of iterations this time is that with every incremental improvement of AI more of the work that would require humans can be done by AI.
We will run out of the next thing for humans to replace their current role with.
Hope I'm gone before we find out if we can handle the transition.
As we replace more and more software creation use cases with tooling, it's possible that we at some time reach some turning point where software developers would be less sought for, but I don't see it any time soon.
ChatGTP and Copilot are not it. The unreliable output we have seen from ChatGTP and Copilot are not indicators that they are generic tools that can replace hand-crafted tools for specific programming scenarios. We can't leave them unsupervised any time soon. You'll need an expert to check their work, even if that expert might (or might not) be faster with the large language model assisting.
@Moon@clacke Idiots have said this about every new technology since BASIC. Now so-called "no code" solutions are being pushed everywhere. But this is what happens:
1. Buy expensive no-code solution. Now business can make software without expensive programmers! 2. This is hard to use, we need to hire specialists. 3. Programmers are hired to use "no code" solution. 4. Because they work for business, they are not subject to all the audit requirements that programmers are. 5. "No code" programmers get stuff done faster because they don't have to document requirements, go through QA, have actual production access, don't have to talk to three departments to get anything done. 6. Business is now tied to an expensive proprietary product. 7. Auditors will eventually catch on. Auditors are really stupid though, so #5 could go on for a long time.
@Rocket@Moon This is the core complaint of Luddites: Adding automation combined with removing the experts takes away expert jobs, sure, but it also makes for shoddy output and nobody is there to spot it.
@clacke When ever the competent insight to understand, right level of abstraction for simplicity and robust design are omitted things become inadequate pieces of crap without ever enabling satisfaction or value for users
But of course new full-stack engineers may get more diluted experiences from more trial and error with new tools matured for something else - the idea of a tech silver-bullet never goes away ?
@clacke I've lived through it since 1989. But I do think AI adds a different twist in that the programmers that are needed will be increasingly AI and not human.
@Sandra@clacke So did BASIC and some forms of batch file.
I used 4DOS batch language to write the first program I ever made for others to use. I was at a center for the blind. The program took a CD-ROM full of ebooks that were zip files each containing a single .txt file. Using a catalog, it organized that collection into directories named for authors, with the extracted .txt files renamed to contain the title. Yeah, the input was 8.3-style DOS filenames, and the output used Win 9x long filenames.
I was doing most of this in my spare time, writing code on a PDA-like device with a Z80 microprocessor, no 4DOS interpreter in sight. Essentially I was coding by reading the 4DOS documentation. When I did have access to a PC with 4DOS, I'd test pieces of the thing.
I had it make little beeps to indicate progress. Wanna guess how exciting it was to watch that thing run and hear those silly beeps?
I was no programmer at the time; just a person with a brain and great reading comprehension.
@Sandra@clacke All I remember is that it was 4DOS running under Win 95, and it handled long filenames just fine. This was a long time ago and a lot of the details are fuzzy. I wish I still had that code.
@chris@Sandra Oh yeah, I remember now that some command-line tools under Windows 95 were actually capable of doing long filenames. So 4DOS could do that too, that's very cool.