Graduating from an Engineering degree (and/or receiving an Iron Ring) has no real legal protection or obligation. The licensing requirements to become a Professional Engineer (or P. Eng) are as follows:
* Graduate with a degree from an accredited program in engineering or applied science, accredited by the Canadian Engineering Accreditation Board (CEAB).
* Complete an Engineer in Training or "Engineering Internship" program under the direction of a P.Eng. (This is a minimum four-year program with the exception of Quebec)
* Review of work experience by the Association,
* Pass a Professional Practice Exam(content and format of which differs by province).
edit: based on the "Title Usage: Canada" section in the same article, it does look like there were lawsuits and attempts to try and restrict the usage of the word Engineer, but it seems results were mixed at best, and vary widely from province to province, so I'll stand by my point that the only actual protected term is Professional Engineer
Calling yourself an Engineer without having graduated from a CEAB-accredited institution is also illegal, just that people don't care nearly as much as bout this. You will occasionally see job postings and titles for "software engineers" from companies that don't know about this particular legal snag, and for the most part it's not policed.
You will sometimes see this dodged as "Engineering". "Junior Engineering" is a common moniker for someone who hasn't graduated yet, for example. The verb isn't protected, only the noun is.
For example - at my school Comp Sci were allowed to take physics for physics majors instead of physics for engineers. For both electromagnetic physics and mechanical physics. Typically most engineers are required to take some courses in the some basic courses, ie Dynamics, Statics, and others depending on your major. This all assumes that your ABET accredited. Maybe it's because I don't see an accrediting agency/society. http://en.wikipedia.org/wiki/ABET#Members
(2) Every person who is not a holder of a licence or a temporary licence and who,
(a) uses the title “professional engineer” or “ingénieur” or an abbreviation or variation thereof as an occupational or business designation;
(a.1) uses the title “engineer” or an abbreviation of that title in a manner that will lead to the belief that the person may engage in the practice of professional engineering;
(b) uses a term, title or description that will lead to the belief that the person may engage in the practice of professional engineering; or
(c) uses a seal that will lead to the belief that the person is a professional engineer,
is guilty of an offence..."
As can be plainly seen, it is perfectly legal to call yourself a software engineer, audio engineer, sanitation engineer, or any other term which isn't holding yourself out to be a licensed professional engineer. The fine is $10,000.
An audio or sanitation engineer is unlikely to run afoul of this, a software engineer is less clear... I've yet to hear of anyone going after software engineers for the term though.
Source: My dad has served on local APEGGA boards and holds P.Eng and FEC designations.
I think it's one of those things in Canada where nothing happens until a complaint has been filed. Having said that, even though my job title is "Platform Engineer," as somebody with a CS degree living in Canada, I avoid using it when I'm away from the web, lest it prompt somebody to complain against my employer.
I addressed this in another post, but this is not true. Microsoft temporarily advised holders to use the abbreviation instead of the full name, but then reverted to the full name (see my other post on this for a story on this from the PEO themselves). Years later they changed the whole program to "IT Professional" worldwide in a new marketing push to split the development track from the administration track.
I think it's one of those things in Canada where nothing happens until a complaint has been filed.
The Professional Engineering groups have absolutely no success in trying to coopt the dictionary, nor should they.
There is currently no widespread recognition of the profession in the IT community. We almost never see any job posting requiring the title, or any company giving additional compensation/responsabilities because of the title. For this reason, very few software/IT engineers are going through the process as it is quite costly (~400$ per year + cash spent on minimum Continuing Education Units).
The main difference between a comp sci. degree and a software eng. degree when I graduated in Quebec (circa 2007) was mostly courses about rational rose and the waterfall process. Software Engineer is a nice title and all, but I don't see its advantages over a comp sci. degree.
But I must admit I haven't studied the curriculum of a CS program. Am I wrong to say you can do it in 3 years while SE is 4 years? If we could study a few programs from a few university offerings, I'm sure we could see what is different. I ought to think it is generally an engineering approach to building software, that is a mix of science, people and integrity.
I think that a lot of what you learn in the SE curriculum can be learnt (and probably is better learnt) on the job, as opposed to the very theoretical courses in a CS curriculum that a) cannot be learnt easily by one's self or on the job and b) will last a lifetime.
In 2006-7, it would have been much more useful nowadays for someone to learn about machine learning in an AI class than about rational rose and the waterfall process, and I suspect the same applies now in the CS vs SE debate, except with updated technologies.
CS: This program is the standard Major program offered by the School of Computer Science. It provides a broad introduction to the principles of computer science and offers ample opportunity to acquire in-depth knowledge of several sub-disciplines. At the same time, its credit requirements allow students to take an additional minor.
SE: This program provides a broad introduction to the principles of computer science and covers in depth the design and development of software systems.
For example, I recall that my SE program had some common courses with other engineering branches (ethics and technology, entrepreneurship, communication, finances for project manager), which were common to all engineering disciplines.
Now, if the World of Academia could attempt to catch up with technology (I know, it's a mad mad world that travels at high velocity and may even continue to accelerate, but a guy can dream) and start offering detailed courses of study for Computer Engineers & Architects, Data Engineers & Architects, Software Engineers & Architects, etc ... will the physical engineering world still have a problem with sharing their title?
Just a short list of terms which we've appropriated for software:
Bugs that don't bite, computer mice that don't squeak, bits you can't bite, windows you can't see through, desktops which do not involve desks, perls you can't wear, pythons which are neither British or snakes, rubies which are not red, gnu's which do not roam plains, dog-fooding which involves neither dogs or food, running which does not involve feet, killing things which does not involve death, zombies which are real, frameworks which do not involve lumber, libraries which do not involve books, bricks which cannot be built with, ajax you cannot clean with, bandaids that do not stop bleeding, androids which are not humanoid, chatting without talking, hits that are not violent, etc.
If we're going to perform all these pedantic semantic antics (did I really just do that?), then allow me to ruminate a moment: I do "develop" software. "Develop" has this connotation in my mind of a slow, meandering, possibly goal-free path. You "develop" skills over time - are they ever fully developed? Also, you "develop" film (and its prints) which certainly takes time, but is also kind of a curated, artistic process. Although I do feel that, at times, I sculpt, craft and develop a bit of software, I do this with ideas that are not quite formed; goals which are unknown; a kind of "I'll know it when I see it" project.
I do "architect" systems. I have to decide on a backing store and the shape of the data in the store: RDBMS? KV Store? binary blob on disk? I have to decide on a communication method between the app and the data store: local, native API? Network socket using the store's client libs? HTTP CRUD? I have to consider the ways the user will use this app: touch? mouse? keyboard? does it need new gestures? "hot keys" or "chording"? I'll admit the user interaction is a bit more art, but there's usually some kind of specification for it.
I do "engineer" systems. This feels more like implementation to me: I implement that data design; I implement the communication code (APIs don't plug themselves in to my project); I work around pitfalls and shortcomings continuously ...
I am an artist, a sculptor; I am an architect and engineer; I am a handy-person and problem solver. Hi, I'm delinka and I create software.
Developer.
Peter Naur (of Backus-Naur form) called it "theory-building". https://dl.getdropbox.com/u/502901/naurtf.pdf
The difference in difficulty between computer science courses and the engineering courses is like night and day, so it doesn't really surprise me when my EE/CE friends are frustrated when compsci majors try to call themselves engineers.
The attitude you describe of your EE/CE friends very much reminded of a fortune file quote that's been floating around for quite some time:
"Yes, I am a real piece of work. One thing we learn at ULowell is how to flame useless hacking non-EE's like you. I am superior to you in every way by training and expertise in the technical field. Anyone can learn how to hack, but Engineering doesn't come nearly as easily. Actually, I'm not trying to offend all you CS majors out there, but I think EE is one of the hardest majors/grad majors to pass. Fortunately, I am making it." -- "Warrior Diagnostics" ([email protected])
"Being both an EE and an asshole at the same time must be a terrible burden for you. This isn't really a flame, just a casual observation. Makes me glad I was a CS major, life is really pleasant for me. Have fun with your chosen mode of existence!" -- Jim Morrison ([email protected])
In addition, as someone mentioned elsewhere in the comments, the cost of failure in software doesn't often result in death.
That's nice; perhaps you should tell it to the victims of the Therac-25. Or maybe I'll remember it next time I'm writing some real-time software to control something silly like missile guidance. More and more software every day goes into controlling vital systems in our world . . .
And how often do certified professional engineers design something critical? Does every circuit that goes into a consumer electronics device need to be ultra-safe?
I'll grant you, there are a lot of shitty "software engineers" that have no business writing critical software. And many CS programs are severely lacking. But I picked up electronics in high school in my spare time, which makes me about as much an EE as your self-taught development skills make you a software engineer or architect.
What gets me is the arrogance, in particular since the Iron Ring is supposed to carry with it a reminder that everyone is fallible, and to have humility in the face of that. More often than not, things like the iron ring set people apart, for better or for worse. There are plenty of hard things that people's live depend upon that nobody gets accredited for. Having some humility, and empathy, would go a long ways towards making Professional Engineers not just better people, but better Engineers.
Having picked up electronics in your spare time, I doubt you'd go around calling yourself an electrical engineer. On the flip side, it happens all the time where self-taught programmers will call themselves software engineers.
Finally, I don't see how you can disagree that software failures don't often result in death. I never said they "never" result in death. It's just that software applications that have life-threatening consequences aren't nearly as common as in traditional engineering. See: cars, bridges, building structure, ropes, pulleys, levers, bolts etc. I'd argue these are more commonplace than missile guidance systems.
Those three things right there commonly have embedded software monitoring or controlling them. As far as levers and bolts go, a lot of them have sensors monitored by software for stress.
I really don't think most people, even software developers, realize how pervasive software is in their lives.
That's in the far minority of situations. As part of my ME curriculum, I've worked with these types of sensors. It's very rare you'll find them monitoring bolts and levers.
It's true that software is extremely pervasive, however I believe you're overestimating the critical nature of it in most applications. Cars, bridges, buildings: Most critical failure points are mechanical. There's certainly a lot of software the goes into regulating a car, but if there's a failure in either the software or mechanics of the car, mechanical failure will most often be the more serious issue.
Given that many mechanical and structural components are designed with the assistance of software that analyzes the stresses they are subjected to (and sometimes little or no analysis is performed beyond software simulation), one might question if it’s even possible to underestimate the role of software.
The point is that software is an ever-increasing percentage of the most common items around us and as a result, its impact on our lives grows every day.
mechanical failure will most often be the more serious issue When the software is so tightly interlinked with the sensors and mechanisms that they are otherwise useless, you can no longer make that statement.
At a more fundamental level, all components related to mechanical advantage that are so prevalent in our lives, yet mostly forgotten (gears, screws, levers, pulleys, wedges, etc.) are not being replaced by microcontrollers or actuators. You'd be hard pressed to find a better software+electronic component solution to solve the problem that the screw solves.
I assure you, I love software far more than I've ever loved mechanical engineering, but it's naive to think that it will overtake (or even come close to being more critical than) fundamental mechanics. Aside from information and communication, software only serves as a proxy for control over our physical world. I guarantee you that if you were to take a look around, the amount of pure "stuff" derived from basic engineering greatly dwarfs that derived from software.
While we could live in a shittier version of our world without software, we couldn't live in a world without traditional engineering.
Yes. Totally agree. This idea that software engineers (perhaps I should use a different title in this thread :-) can fail without consequence is nonsense these days. I actually find it quite amusing (terrifying?) that so many engineers I know think they are a-okay with only a very basic understanding of CS. In fact, often "CS" is too strong a term to describe their knowledge. There's a very pervasive sentiment among engineers that they don't like programming, don't want to program, and shouldn't need to know about programming, let alone the deeper concepts of CS. Of course, a huge chunk of them go on to work with systems that involve computers. :-/
>And how often do certified professional engineers design something critical? Does every circuit that goes into a consumer electronics device need to be ultra-safe?
Indeed, every PCB that goes into your microwave doesn't need to be EMP hardened and fault tolerant, and likely is not. But then also many of those applications that have become "commodity engineering" are no longer done by north american trained, "certified professional engineers". In any case, I think the point is you need to be trained so that you have the background to deal with a critical situation if it comes up.
>What gets me is the arrogance, in particular since the Iron Ring is supposed to carry with it a reminder that everyone is fallible, and to have humility in the face of that
Well, I have to mildly disagree with this. The ring is there to remind you that you are morally and ethically bound to the public good, at least insofar as your work is concerned. Many engineers are fiercely arrogant and could use a lesson in humility, but that's the job for parents/teachers/themselves/society in general, not a stainless steel torus or their professional association. As with many "old boys club" type groups, there is a serious amount of hazing and dues-paying that happens on the way up, and that has the effect of seriously distorting the perceptions of a lot of engineers. Also, a lot of the folks who are hotheads and spew arrogance are the types who would do that no matter where they were, be it on the soccer pitch or on HN. Being an engineer simply gives these types more opportunities, and an appeal to authority.
>Having some humility, and empathy, would go a long ways towards making Professional Engineers not just better people, but better Engineers.
Having some humility, and empathy, would go a long ways towards making <social segment> not just better people, but better <members of social segment>.
Agreed :-)
Hell, many of the courses have huge overlaps in material, and both programs allow the courses in the other programs to be substituted for each other. I'm not arguing that CPSC majors should be allowed to call themselves engineers, but I believe you might be mistaken as to how different the two programs/fields may be.
My father was a CPA, and he used to occasionally go on a little rant about the distinction between CPAs and accountants.
Anywhere else doesn't care and will call the guy taking out the garbage a Sanitation Engineer if they feel like it.
Similarly, countless people use the title Software Engineer, just as there are Sanitation Engineer and Train Engineers.
Because the PEO has more bark than bite.