question, When were programmers supposed to be obsolete?
!Programmer Humor
Hi, this is a question that popped into my mind when i saw an article about some AWS engineer talking about ai assistants taking over the job of programmers, this reminded me that it's not the first time that something like this was said.
My software engineering teacher once told me that a few years ago people believed graphical tools like enterprise architect would make it so that a single engineer could just draw a pretty UML diagram and generate 90% of the project without touching any code,
And further back COBOL was supposed to replace programmers by letting accountants write their own programs.
Now i'm curious, were there many other technologies that were supposedly going to replace programmers that you remember?
i hope someone that's been around much more than me knows something more or has some funny stories to share
astro_ray
in reply to Giovanni Petri • • •Scrubbles
in reply to Giovanni Petri • • •It's happened a few times in my career where people tell me I'll be obsolete, but it's always been some company hyping their new product and suits frothing at the prospect of not having to pay me anymore.
So far they're like 0 for 8 or so.
Now I will say the goalposts move. What I'm doing now is for sure not what I was doing 10 years ago. I'm definitely heavier in devops and infra than where I was before (ironic because they said we'd never have to worry about that stuff again if we moved to the cloud). AI is still basically machine learning, just in a while loop, so I've spent time learning that. So, in a way, yes we're obsolete in the sense that if I was the same engineer I was 10 years ago I wouldn't be worth nearly this much, I had to grow and evolve with technology.
Giovanni Petri
in reply to Scrubbles • •@Scrubbles
cool
i half expected it, after all it's what's happening right now
that's right, i guess some aspects of programming have really been made obsolete
corsicanguppy
in reply to Giovanni Petri • • •I'd agree that some specifics have been made obsolete. Some habits and routines are currently being ignored or skipped, but the amount of skill that's gone away is very small.
As mentioned before, we downsized brutally after Y2K. The people most affected were the highest-paid who weren't the best code-grinders, and these were the documenters, the programme people, and the mentor types. We lost our guides, our structure, and our historians. We've been growing again like feral children rebuilding society from the wasteland like it's Mad Max, and there's a LOT of the Why that we either don't know, that we ignore, or that we skip in the interests of (insert manufactured urgency here).
We are re-learning some of the whys, but we haven't yet seen the half-assedry chickens come home to roost on that. The symptoms are there: Boeing's Gilligan's Island in Space, supply-chain sploits in waves, personal information lost weekly, all these things that are clipboard hassles we stopped doing that pelrevent massively expensive things later.
Crowdstrike may die now, mainly because they were marauding leopards we allowed to eat our face. Solarwinds before that, same issue but they seem to be okay. There are dozens of ohShit moments that could lead to similarly preventable problems, that we knew not to do ... once.
Well get there again but we'll be rediscovering a lot of what some techbro will claim is obsolete, old-practice, too-cautious, hand-wringing in our neu and moderne go-hard/break-lives paradigm.
python
in reply to Giovanni Petri • • •litchralee
in reply to Giovanni Petri • • •I know this is c/programmerhumor but I'll take a stab at the question. If I may broaden the question to include collectively the set of software engineers, programmers, and (from a mainframe era) operators -- but will still use "programmers" for brevity -- then we can find examples of all sorts of other roles being taken over by computers or subsumed as part of a different worker's job description. So it shouldn't really be surprising that the job of programmer would also be partially offloaded.
The classic example of computer-induced obsolescence is the job of typist, where a large organization would employ staff to operate typewriters to convert hand-written memos into typed documents. Helped by the availability of word processors -- no, not the software but a standalone appliance -- and then the personal computer, the expectation moved to where knowledge workers have to type their own documents.
If we look to some of the earliest analog computers, built to compute differential equations such as for weather and flow analysis, a small team of people would be needed to operate and interpret the results for the research staff. But nowadays, researchers are expected to crunch their own numbers, possibly aided by a statistics or data analyst expert, but they're still working in R or Python, as opposed to a dedicated person or team that sets up the analysis program.
In that sense, the job of setting up tasks to run on a computer -- that is, the old definition of "programming" the machine -- has moved to the users. But alleviating the burden on programmers isn't always going to be viewed as obsolescence. Otherwise, we'd say that tab-complete is making human-typing obsolete lol
mechanical analogue computer designed to solve differential equations by integration
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)Giovanni Petri
in reply to litchralee • •@litchralee
Thank you!
i didn't expect serious answers here, but this was a nice read,
so the various jobs around computers were kind of obsoleted, but the job description just shifted and the title remained valid most of the times,
now i'm interested to see what we'll do 20 years from now rather than just being annoyed by the "don't learn ${X}, it's outdated" guys
Phen
in reply to Giovanni Petri • • •If a tool were created that properly converted an UML diagram into a project without any need for code, all the programmers that lost their job to this tool would then be hired by the company that offered it, in order to give maintenance and support to everything the customers want in their programs.
It would be removing programmers from they payroll of some companies but they would still be working for them, just further down in the chain.
The same is true for AI. If AI could completely replace programmers in some area, it would need a lot of programmers itself to keep dealing with all the edge cases that would show up from being used everywhere that a programmer was needed before.
👍Maximum Derek👍
in reply to Giovanni Petri • • •Tiefling IRL
in reply to Giovanni Petri • • •HubertManne
in reply to Giovanni Petri • • •Ephera
in reply to HubertManne • • •But then it only comments the 'what', it cannot possibly know the 'why'. I know, some devs disagree on that, but personally, I would rather not have what-comments in my code.
HubertManne
in reply to Ephera • • •BeigeAgenda
in reply to Giovanni Petri • • •Rational Rose etc. could generate code from UML diagrams, then you "only" needed architects.
In reality it only gave a little help during the design phase, as soon as someone touches the generated code, you have to manually merge changes to UML.
Avid Amoeba
in reply to Giovanni Petri • • •Stefen Auris
in reply to Giovanni Petri • • •Someone has to build the AI after all
SavvyWolf
in reply to Giovanni Petri • • •invertedspear
in reply to Giovanni Petri • • •NigelFrobisher
in reply to Giovanni Petri • • •tias
in reply to Giovanni Petri • • •Oracle has a product called Oracle Policy Automation (OPA) that it sells as "you can write the rules in plain English in MS Word documents, you don't need developers". I worked for an insurance organization where the business side bought OPA without consulting IT, hoping they wouldn't have to deal with developers. It totally failed because it doesn't matter that they get to write "plain English" in Word documents. They still lack the structured, formal thinking to deal with anything except the happiest of happy paths.
The important difference between a developer and a non-developer isn't the ability to understand the syntax of a programming language. It's the willingness and ability to formalize and crystallize requirements and think about all the edge cases. As an architect/programmer when I talk to the business side, they get bored and lose interest from all my questions about what they actually want.
Elise
in reply to Giovanni Petri • • •yogsototh
in reply to Giovanni Petri • • •