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