[−]probably_wrong · 2026-11-14 Sat 22:07 UTC ·
link
Recently I spoke to someone who wanted to know what they should call themselves seeing as they never learned software development, formally or otherwise, but that's not stopping them from releasing AI-powered Python projects in GitHub. I suggested Project Manager, but they took offense to that because (I think) they wanted to hear Software Engineer in order to apply to those jobs. My counter-argument was that, legal rules aside, a S.E. should be able to differentiate good code from bad, but my suggestion wasn't super well received.
The point being: I'm always amazed at the cross-purpose impulse of arguing "the title is not important" while, simultaneously, really wanting to use the title.
If you look up the etymology of engineer, you'll find ancient roots (Latin, etc.) many hundreds of years old which are primarily about contriving/inventing/designing clever devices and occasionally about operation thereof. And you can find that a definition regarding train operators was added less than 200 years ago. The train thing is just an offshoot that is irrelevant to other types of engineering.
I would suggest "Anthropic client", because the relationship between them and Anthropic is similar to the relationship between a client and a contractor.
You ask the contractor for what you want, iterate a little, and take what they give you. Sometimes you may read the results.
Nobody calls the person that manages a company’s external contracts a client internally though, we call them something like “contract manager” or “acquisitions specialist” if the contract is with a manufacturer.
Project Manager is a great fit. I also heard and liked Director, which brings in good analogies from filmmaking and implies nothing about technical ability either way. Could even be Software Director.
"The title is not important" was a movement coming from the fact that same jobs at two companies could've had vastly different responsibilities, and vice versa. But that was rather an exception and outside that bubble, people have always paid great attention to titles.
Yours sincerely, Software Developer with 6 years of experience. Last week for the first time in my career I've actually merged application code. It was AI generated.
As an analyst who vibe codes a lot I think it is perfect, along with Product Manager. There is a lot more to these roles, but I think they're the closest.
[−]disgruntledphd2 · 2026-11-15 Sun 08:27 UTC ·
link
Product rather than project makes much more sense for vibe coding.
It's a weird one, because recently I've been working on a JS based system when I don't know JS and it's definitely very very different from when it's a language you're familiar with.
There's only one country to my knowledge that has historically allowed anyone to be called a software engineer without being an engineer . Now that the bar is dropping even lower, can we stop normalizing that? I never had the audacity to call my self a Software Engineer without an Engineering degree, just use any of the other dozens of words.
Comp Sci degree is somewhat of an exception, I get that
A nutritionist, the non protected title / non licensed person.
[−]gremlinunderway · 2026-11-15 Sun 15:15 UTC ·
link
Except dietician is a protected job title that is licensed by legally-recognized professional standards bodies.
Software "engineers" in North America don't have any actual professional board that licenses or oversees their work. Until governments actually regulate the profession through these bodies, no one can gatekeep software development job titles.
A bunch of blog posts talking about "industry standards" is not a reference point for this.
AI is heavy machinery. In the construction industry you need special permits to operate such machinery, and everybody driving a car needs to have a driver's license.
So I wonder if users of "heavy AI" should also need to have a license.
Do people die or get maimed if you drive your model wrong?
Will your model and harness be the same in enough time to develop a curriculum for it and disseminate that to enough people to give it enough of a reputation to be worth doing for students, before it's obsolete?
I'd argue no on both counts.
This work has key differences vs operating heavy machinery.
Depends entirely on what people are doing with the model! If they're working in safety-critical areas and liberally applying AI without sufficient domain knowledge or oversight, then yes, absolutely, mistakes can be life-threatening.
Off the top of my head: healthcare (diagnosis, medication, treatment decisions), engineering (structural design, electrical systems), aviation, autonomous vehicles, industrial automation, chemical processing, power grids, cybersecurity of critical infrastructure, or even software controlling medical devices.
IMO you don't have to be physically operating heavy machinery to make a mistake that get someone killed. I would posit it has already happened and will continue to happen.
I think the role is that of a producer - similar to a music producer in the 70s and 80s integrating new synth and recording technology into ambitious outcomes where the goal was defined but the shape and detail unpredictable.
It depends on the way they use it. If you design an architecture and use an LLM to fill it in, I'd consider a more technical label. If you're just using what Claude made, and providing feedback, that's just how software was done 10 years ago except then they'd be talking to a guy instead. And it would be orders of magnitude more expensive.
From my perspective, Claude feels like 5 engineers in a box. you can make things that required small organizations to make.
This is shortsighted (no offense). We should collectively stop personifying AI tools like this before we’ve completely lost our way.
If you’re building and producing valuable software, you are still a creator or software engineer full stop. We can argue over titles, but don’t demote your own creative process to passive consumption.
I have a bachelor of Software Engineering that is fully accredited by the Australian institute of Engineers. It was two years longer than a C.S. Degree.
Software Engineering is about so many things other than code it was an ongoing debate if code and programming should even be taught at a university level course, and while contemplating my masters of S.E. I had many great conversations with faculty about the distinction. Writing code is much more akin to welding or wiring, therefore belongs at a trade school, not a university.
After all, the discussion goes, Aerospace and Electrical Engineers don’t learn the doing of welding or pulling wires through crawl spaces, why should Software Engineers concern themselves with the doing of code.
>a S.E. should be able to differentiate good code from bad
A software Engineer needs to have all phases of the SDLC in mind, and be thinking about and planning all of them. Code is a tiny piece of the puzzle.
I’m thinking about requirements gathering, designing, testing, deployment, maintenance, long term change strategy, hand off to a new owner, etc, etc.
I could always see the merits of both sides of the discussion.
Then at my first few jobs it very quickly became clear that many CS grads were just there to write code and that’s it. They didn’t have the big picture ideas at all, and I immediately understood the difference of a Software Engineer.
Just let me give my 2ct: as somebody that did search for hiring EEs and mechanical engineers, I really searched hard for the ones that DID soldered, pulled wires and welded, even for management positions. They use to manage much better, had better communication with the team, had better feeling for quality, could look much further in the furure and had much more authority, were way more respected by the team.
That being said, another 2ct:
> A software Engineer needs to have all phases of the SDLC in mind, and be thinking about and planning all of them. Code is a tiny piece of the puzzle.
I would not AT ALL call it tiny. Yes, is one part of MANY. But is your final delivery. Would be like Toyota saying: “hey they don’t really have to understand what makes a good car, the cars we sell is a tiny portion in the whole development cycle”. SW engineers do need to tell apart good from bad code, as much as good from bad tests and good from bad requirements. After all, if I somehow manage to deliver good SW (working and documented) I don’t gove a crap how the requirements and teat work or don’t in the company.
I remember a professor who used to say “If the requirements, design, test plan and acceptance criteria are done to a high enough standard, the code can be written by a monkey.”
Which is exactly what we’re seeing now with LLMs writing code.
Interestingly you’ll see the same building a mega bridge or skyscraper. As long as the plan has been done well, it can be assembled by relatively very unskilled labor.
Note the test plan and acceptance criteria could be one and the same, depending.
> If the requirements, design, test plan and acceptance criteria are done to a high enough standard, the code can be written by a monkey.
Nice sentence. But it has 2 problems:
1) Define "high enough" - There is where good requirements start, make it measurable! (How much is going to cost?)
2) Related to "you’ll see the same building a mega bridge or skyscraper". I've seen enough cases where "unskilled labor" messed up building something. You will reply "that is why I said 'Acceptance Criteria'!". My take is: you are making it far more complicated than it should, taking totally unnecessary risks, and it will be invariably more expensive in the long run.
I mean, I've seen enough examples of cases where the acceptance criteria was not properly checked, because also the ones doing the test were "unskilled" and had received a "perfect plan". (Just look at any infrastructure disaster we have every year)
And even in the best case: you discover the poured cement does not meet the specifications. What now? Blow the thing and start over? Better to have skilled labor.
Again, my 2ct. experience: hire experienced people, who actually have done the work all the way down to the lowest level.
"If you think knowledge is expensive, try with ignorance"
[−]randomaccountpe · 2026-11-15 Sun 10:30 UTC ·
link
I’ve heard this argument before about software engineering vs CS, and it’s just super untrue. Especially for most Australian/NZ universities, where the software/math focused courses are basically copy-pastes of each other regardless if you do CS or SE.
I only particularly mention this, as it sounds like your argument has shifted from "What does software engineering entail" -- to -- "What is software engineering that CS student's don't learn"
SDLC and other “engineering” concepts are all in computer science for most universities. The line you’re drawing between CS and SE grads just doesn’t exist in practice.
Also, where did you find a 5 year long software engineering bachelor’s?
As far as I’m aware, most pipelines are a 3 year bachelor’s degree in compsci. Or a 4 year long engineering bachelor’s with honours, in software engineering.
I normally don’t post, but these sorts of comments have always irked me. They give off gatekeepy, “No True Scotsman” vibes.
Funnily enough, this kind of thinking is part of the problem the family tree shows: there are so many different titles that are meaningless, which is what other commenters have pointed out
Electrical Engineering programs have practical labs where you build electronic projects and run wires. Most electrical engineers don't work in power or building engineering. Senior design projects (for undergraduate) have to be mostly built by the students. Metallurgical Engineers and Welding Engineers take welding courses not Aerospace.
Of course no Electrical Engineer would be able to tell you the building code requirements for how close an outlet can be to a sink, or the ground, or a window. Every electrician can.
No Aerospace Engineer will be able to weld strange metal combinations, or be great at aluminum and thick stainless and oil pipeline pipe. Every ticketed welder can.
When you want the doing done, it’s great the Engineer has a working knowledge, which no doubt makes the project better, but no way in hell you get them to do it on the real thing. You get the ticketed tradesperson.
If writing code can be considered a trade, what about debugging? What about debugging a complex embedded system?
I'm not sure what i should call myself. I usually just say programmer because it's easier to say that.
I did an electronics and communications engineering degree at an Aus uni, focusing on DSP and FPGA.
I had 2 FPGA jobs, one in defence and one in medical devices.
Now I've been working with embedded software for 7 years for a chip company.
I'm still not sure if I should call myself a Software Engineer, even though that's what it says on my contract. I occasionally find gaps in my software engineering knowledge, but i learn as i go.
I don't understand the view that coding is like a trade; even with a good idea of the systems involved and an intended design, I often find out things while coding that change the perceived optimal design substantially. I don't think this is nearly as likely to be the case with wiring or welding, and may even be impractical to change regardless given the less mutable nature of the metal or electrical systems you're working with.
Cannot be an engineer without corresponding university title, be it mechanical, construction or software etc. Same as doctor or lawyer for example. Various emotional insecurities of wannabe-whatever are not that relevant here.
That really depends on the country and the spelling of title. In the Netherlands only the dutch version of the word is protected for instance. And other countries don't have protection.
Until recently you could get licensed as a Professional Engineer without a degree at all in my state (with the exams) and even today there is an waver process for 15 year of lawful practice elsewhere (my great uncle did this).
[−]gremlinunderway · 2026-11-15 Sun 15:17 UTC ·
link
Nope.
Actual engineers, doctors and lawyers are given that title not through their universities but through legally-recognized standards bodies. These are standards bodies that certify them, review their work, can investigate deviations from standards and even delicense people if needed. These standards bodies may require university education too, but they set the standards and certify professionals, not the university.
In North America, there aren't any such bodies for software development. So trying to gatekeep this term because of a university degree is absolutely not the same thing as lawyers, doctors or mechanical engineers.
I would be fully supportive of gatekeeping this btw if such professional bodies (recognized by law, not just self-initiated) existed, but pretending that the title software engineer is the same as mechanical engineers, doctors and lawyers is ridiculous. Lawyers have to pass the bar and maintain certification with the bar, and can be decertified if found to be performing outside of those standards.
Until there are actual standards bodies overseeing this, sorry, your university degree equally means the same as anyone self-taught so long as no one actually oversees the work and certifies people.
Pretending your university degree qualifies you to this is equally emotionally sensitive ("but but but my university WAS SUPER DUPER HARD U GUYZ")
The titles between different levels don't seem to mean much because of the variation between companies. But I do see merit to differentiating between roles.
As an example, I moved from Software Engineering to IT Controls Analyst. The pay brackets are lower and there are way fewer job postings. Even this chart of software related job completely leaves out any compliance or audit function, illustrating just how little my own profession thinks of us.
The point being: I'm always amazed at the cross-purpose impulse of arguing "the title is not important" while, simultaneously, really wanting to use the title.
I don't think so.
You ask the contractor for what you want, iterate a little, and take what they give you. Sometimes you may read the results.
Yours sincerely, Software Developer with 6 years of experience. Last week for the first time in my career I've actually merged application code. It was AI generated.
I'm confused about the point he's making here with the 6 years thing.
It's a weird one, because recently I've been working on a JS based system when I don't know JS and it's definitely very very different from when it's a language you're familiar with.
Comp Sci degree is somewhat of an exception, I get that
Software "engineers" in North America don't have any actual professional board that licenses or oversees their work. Until governments actually regulate the profession through these bodies, no one can gatekeep software development job titles.
A bunch of blog posts talking about "industry standards" is not a reference point for this.
So I wonder if users of "heavy AI" should also need to have a license.
Will your model and harness be the same in enough time to develop a curriculum for it and disseminate that to enough people to give it enough of a reputation to be worth doing for students, before it's obsolete?
I'd argue no on both counts.
This work has key differences vs operating heavy machinery.
Off the top of my head: healthcare (diagnosis, medication, treatment decisions), engineering (structural design, electrical systems), aviation, autonomous vehicles, industrial automation, chemical processing, power grids, cybersecurity of critical infrastructure, or even software controlling medical devices.
IMO you don't have to be physically operating heavy machinery to make a mistake that get someone killed. I would posit it has already happened and will continue to happen.
It depends on the way they use it. If you design an architecture and use an LLM to fill it in, I'd consider a more technical label. If you're just using what Claude made, and providing feedback, that's just how software was done 10 years ago except then they'd be talking to a guy instead. And it would be orders of magnitude more expensive.
From my perspective, Claude feels like 5 engineers in a box. you can make things that required small organizations to make.
If you’re building and producing valuable software, you are still a creator or software engineer full stop. We can argue over titles, but don’t demote your own creative process to passive consumption.
Software Engineering is about so many things other than code it was an ongoing debate if code and programming should even be taught at a university level course, and while contemplating my masters of S.E. I had many great conversations with faculty about the distinction. Writing code is much more akin to welding or wiring, therefore belongs at a trade school, not a university.
After all, the discussion goes, Aerospace and Electrical Engineers don’t learn the doing of welding or pulling wires through crawl spaces, why should Software Engineers concern themselves with the doing of code.
>a S.E. should be able to differentiate good code from bad
A software Engineer needs to have all phases of the SDLC in mind, and be thinking about and planning all of them. Code is a tiny piece of the puzzle.
I’m thinking about requirements gathering, designing, testing, deployment, maintenance, long term change strategy, hand off to a new owner, etc, etc.
I could always see the merits of both sides of the discussion. Then at my first few jobs it very quickly became clear that many CS grads were just there to write code and that’s it. They didn’t have the big picture ideas at all, and I immediately understood the difference of a Software Engineer.
That being said, another 2ct:
> A software Engineer needs to have all phases of the SDLC in mind, and be thinking about and planning all of them. Code is a tiny piece of the puzzle.
I would not AT ALL call it tiny. Yes, is one part of MANY. But is your final delivery. Would be like Toyota saying: “hey they don’t really have to understand what makes a good car, the cars we sell is a tiny portion in the whole development cycle”. SW engineers do need to tell apart good from bad code, as much as good from bad tests and good from bad requirements. After all, if I somehow manage to deliver good SW (working and documented) I don’t gove a crap how the requirements and teat work or don’t in the company.
Which is exactly what we’re seeing now with LLMs writing code.
Interestingly you’ll see the same building a mega bridge or skyscraper. As long as the plan has been done well, it can be assembled by relatively very unskilled labor.
Note the test plan and acceptance criteria could be one and the same, depending.
That "if" is doing an unrealistic amount of lifting, here, in practice, and that's probably why human coders have had a better run than monkeys.
Nice sentence. But it has 2 problems:
1) Define "high enough" - There is where good requirements start, make it measurable! (How much is going to cost?)
2) Related to "you’ll see the same building a mega bridge or skyscraper". I've seen enough cases where "unskilled labor" messed up building something. You will reply "that is why I said 'Acceptance Criteria'!". My take is: you are making it far more complicated than it should, taking totally unnecessary risks, and it will be invariably more expensive in the long run.
I mean, I've seen enough examples of cases where the acceptance criteria was not properly checked, because also the ones doing the test were "unskilled" and had received a "perfect plan". (Just look at any infrastructure disaster we have every year)
And even in the best case: you discover the poured cement does not meet the specifications. What now? Blow the thing and start over? Better to have skilled labor.
Again, my 2ct. experience: hire experienced people, who actually have done the work all the way down to the lowest level.
"If you think knowledge is expensive, try with ignorance"
I only particularly mention this, as it sounds like your argument has shifted from "What does software engineering entail" -- to -- "What is software engineering that CS student's don't learn"
SDLC and other “engineering” concepts are all in computer science for most universities. The line you’re drawing between CS and SE grads just doesn’t exist in practice.
Also, where did you find a 5 year long software engineering bachelor’s?
As far as I’m aware, most pipelines are a 3 year bachelor’s degree in compsci. Or a 4 year long engineering bachelor’s with honours, in software engineering.
I normally don’t post, but these sorts of comments have always irked me. They give off gatekeepy, “No True Scotsman” vibes.
Funnily enough, this kind of thinking is part of the problem the family tree shows: there are so many different titles that are meaningless, which is what other commenters have pointed out
Of course no Electrical Engineer would be able to tell you the building code requirements for how close an outlet can be to a sink, or the ground, or a window. Every electrician can.
No Aerospace Engineer will be able to weld strange metal combinations, or be great at aluminum and thick stainless and oil pipeline pipe. Every ticketed welder can.
When you want the doing done, it’s great the Engineer has a working knowledge, which no doubt makes the project better, but no way in hell you get them to do it on the real thing. You get the ticketed tradesperson.
Actually, no. It is a HR concern. HR need to put people into boxes. Most people dont actually fit but whatever.
Actual engineers, doctors and lawyers are given that title not through their universities but through legally-recognized standards bodies. These are standards bodies that certify them, review their work, can investigate deviations from standards and even delicense people if needed. These standards bodies may require university education too, but they set the standards and certify professionals, not the university.
In North America, there aren't any such bodies for software development. So trying to gatekeep this term because of a university degree is absolutely not the same thing as lawyers, doctors or mechanical engineers.
I would be fully supportive of gatekeeping this btw if such professional bodies (recognized by law, not just self-initiated) existed, but pretending that the title software engineer is the same as mechanical engineers, doctors and lawyers is ridiculous. Lawyers have to pass the bar and maintain certification with the bar, and can be decertified if found to be performing outside of those standards.
Until there are actual standards bodies overseeing this, sorry, your university degree equally means the same as anyone self-taught so long as no one actually oversees the work and certifies people.
Pretending your university degree qualifies you to this is equally emotionally sensitive ("but but but my university WAS SUPER DUPER HARD U GUYZ")
As an example, I moved from Software Engineering to IT Controls Analyst. The pay brackets are lower and there are way fewer job postings. Even this chart of software related job completely leaves out any compliance or audit function, illustrating just how little my own profession thinks of us.