Professional engineers in disciplines have to sign their name to their designs in fields such as electrical, mechanical, structural and civil engineering, and can be held personally liable, monetarily, losing their license, and perhaps at the extreme end, criminally liable.
Software "engineers" are not.
Licensed Professional Engineers are also bound by a code of ethics by the appropriate industrial organization. e.g. for electrical engineers, you're bound by the IEEE code of ethics, even if you dont practice in the field.
I'm a licensed electrical engineering intern (I've been a licensed EE intern for 16 years now), but work entirely with software; I've never worked as an EE, nor have I met the professional requirements to take the PE exam. I'm still professionally bound by the IEEE code of ethics. I have objected to certain "projects" over the years because of potential violations. I almost quit one job because I was being pressured to violate the code, but my boss was fired and the pressure disappeared.
Such a licensing and accountability doesn't exist in software "engineering".
That said, I do refer to myself as an engineer and not a developer, because, well, I am an engineer. I follow different practices than web developers because I work in finance and theres billions of dollars on the line if I fuck up. I also work at a firm that requires disclosure of any professional licenses and an attestation that you are in good standing with the governing body (which I am). Professional Engineer (Intern) its not on the list of options, so I always have to type it in, they're mostly looking for CPA types.
Accreditation does not change what a discipline is; it is merely a governance mechanism to determine who is capable of it.
Physicians practiced medicine long before there were formal licenses (and long after for that matter...see 3rd world discount medical/dental).
> Such a licensing and accountability doesn't exist in software "engineering".
That's not 100% true. There's Cisco certification, PCI certification. There's no HIPAA certification, but violations can and do cost millions.
Nor is it true that other engineering disciplines always require certifications. You can be a happily employed mechanical engineer without sitting for the PE exam.
I digress...the whole thing is a red herring. The definition of a discipline exists independent of the whatever accreditation procedures happen to exist.
When I was studying engineering in the early 2000's my degree was structured such that in the first year all the engineering students (regardless of whether they intended on majoring in Chemical, Civil, Mechanical, Electrical etc) all took a common set of courses.
This included classes such as:
Calculus, Linear Algebra, Physics, Chemistry etc.
There were two required CS courses (one in the first semester of first year and one in the second) The first semester course was "Intro to programming and algorithms" which began by assuming no one had any prior programming experience and started with the very basics "This is a variable", "This is a function" "This is a conditional statement", "This is a loop" that sort of thing. Eventually it covered algorithms like quicksort, bubblesort etc and really helped get you into the mindset of "This is how you use programming to solve a problem" For example I remember writing code to solve simultaneous equations (i.e Linear Programming), finding line of best fit through a series of discrete points things like that.
In the second semester the required class was "Intro to software engineering" I remember the course covering things like Object oriented programming - classes/inheritance public/private members and all that stuff, this was a component on unit testing. There was also an essay component to the course I can remember having to write an essay about the Ariane 5 explosion. I really didn't enjoy this course and the impression I got was not a lot of my friends did either.
I can understand the intent of making us sit through the course but in some ways I think it did more harm then good pretty much everyone came out of that class at the end loathing "object oriented" programming. At the time it was kind of a struggle to see the relevance behind the topics covered and even now with 15 years of engineering experience working in manufacturing what we learnt in that classroom is very divorced from what goes on in the real world. When I write code I am, typically speaking, not writing complex software that has multiple reusable components that talk to each other most of the code I write is trying to solve some type of problem. When I write code I'm usually thinking in terms of mathematics and problem solving rather than classes + objects and unit tests, my code tends to be a lot more in the style that was taught in the algorithms course rather than in the software engineering course I suspect quite a lot of "research code" would be similar.
When I studied, our software engineering class was more about process than actual development. About gathering/writing requirements, acceptance requirements, etc. Our final project for the semester started day 1 and didn't end until the week before finals. All sorts of requirements, design, architecture and acceptance documents. Then, we had to implement the system according to the docs.
The project was to define a course scheduling system. Had to be able to define which rooms had which equipment, capacity, etc. Then professors would be able to enter their needs of time and equipment, then we'd have to allocate the classes accordingly.
Designing/creating software.