Or is there a career path one has to take. After how many years in industry a person can start to call himself an engineer?
PS: Also curious what's the nuances of distinction between a Software Developer Vs Engineer?
And as to being strictly enforced, IMO, it's not really enforced for software people, so long as they stick to "engineer" and avoid "Professional Engineer". Plenty of firms have job listings for "Software Engineers" that don't require the P.Eng. credential, plenty of people have easily discovered LinkedIn profiles holding themselves out as Software Engineers, but there's not much enforcement.
There was a push by the Professional Engineers Ontario in the early 2000s to regulate Microsoft's MCSE terminology, but I think it basically failed. IMO, they've given up on regulating the term "engineer" unless it's really egregious, like holding yourself out as a P.Eng. when you're not, or actually doing work that requires a P.Eng. without actually having one.
https://ca.indeed.com/jobs?q=software+engineer&l=Toronto%2C+...
*This may not be true outside of the US
https://ncees.org/ncees-discontinuing-pe-software-engineerin...
I imagine the individuals who obtained these licenses did so for prestige or credibility, to support the idea of licensing for software engineers, or because their work is related to other, more closely regulated engineering disciplines.
Some states try to control the use of “engineer” as a title, at least in some contexts, but I don’t know of any U.S. state that regulates the practice of software engineering, as such, nor of any credible plans to change this.
Depends on the field you are in. Here at least, use of the title as it relates to software is currently driven by the hiring agency/company. If you are hired on as a Software Engineer without a degree, then you are a Software Engineer (at least in title, at that position). You damn well better be able to perform. But you can legally write "Software Engineer" on your tax forms.
In my personal opinion, what differentiates a software engineer from a software developer is the level of engineering rigor required for the development and application of your software in a given environment or system. Are there standards in place that recommend (mandate) you provide certain reasonable assurances (e.g.: verifiable proof derived through specified means) that your software will not yield unexpected behavior? Are there standards in place for a given industry that confine the way you use specific languages (to attempt to ensure the aforementioned unexpected behavior will be minimized or eliminated)? I'm thinking of DO-178B/C, IEC 62304, & MISRA as industry representatives here. If you can digest and navigate these standards, and prove to the applicable regulatory body that you adhered (designed, developed, and tested) to their respective guidance documents, they couldn't give a damn about a degree. You've proven you're aware of the risks your software can pose and how to mitigate them through thoughtful application of standards, rules, and hopefully best practices.
Here's where I'll piss some people off: Would I call a front-end UI developer a "Software Engineer"? Probably not, unless that UI is destined for a system where a developer error could cause harm, property damage, etc. What about a trading system where performance losses measured in nano-seconds could accumulate millions in losses? Possibly, depending on the complexity. My personal metric (based on my own career experience) is "will a screw-up cause harm, loss of life, or irreparable damage/destruction to expensive things". Losing millions in a trade and losing millions in an *craft crash are not equivalent to me personally.
Background: Non-traditional EE trained on avionics hardware who moved into developing safety critical avionics and medical device software and hardware.
The thing you are describing is something different altogether, where the distinction is more about status (e.g I do more important work than you). Usually we handle this with appropriate compensation, but if you are looking for nominal respect, that’s a losing battle. I just saw some kid on LinkedIn, graduates a bootcamp with no job experience at all, changes his title to ‘aspiring developer and data analyst’. Title pimping is a lost cause, and the integrity required to derive status from it is infinitesimally small.
Tech in general has always had this problem, as we mostly got lumped into ‘aren’t you an IT guy?’ for years. It had very little status, and we sort of have the same problem all over again except it’s the barbarian horde of newcomers that give themselves titles that would takes years to sincerely attain. Three month bootcamp straight to a ‘full-stack’ developer, huh? This stuff hurts us in general, and we might as all go back to being called ‘IT people’.
I do agree that software is too big to have a blanket term like ‘Software laborer’. There are ‘ui laborers’, ‘options trading laborers’, ‘infrastructure laborers’, ‘backend laborers’, etc. I wouldn’t want to create classism amongst laborers (you know, real laborers vs not so real laborers), but rather have descriptive branches of our field properly described so we understand what part of this field you specialize in - no status involved. I guess the same way we know what a Podiatrist does exactly, compared to an Orthodontist. There is no Medical Professional or Seriously-Better-Medical Professional.
I wouldn’t put too much weight on the term, marketing values ‘full-stack’ ahead of anything else anyways, which flys in the face of specialization. Probably why such a topic even comes up, if we’re all meant to be generalist, what sets us apart?
What I meant to express is how I personally see our types of work relating to non-software engineering professions. For many physical engineering disciplines there's some type of external regulatory body that you must measure up against for each project you complete, to have that project approved to be "launched". In the UI example: if there's no external body that has to sign off on your work, you can pretty much do whatever the heck you want to get that gorgeous interface in front of a user. The skill required to do so may well dwarf my own, with a million crazy frontend js libraries, web standards, and so forth to memorize and wrangle (not a UI guy, obviously). But in my own admittedly narrow definition, as the work can be done without being answerable to some external body that has to sign off on it, I couldn't call that engineering. Again, it doesn't mean the UI work isn't complex, requiring highly skilled individuals, etc. Of course even safety critical software engineers don't have a regular recertification required. Given that and other differences, even this application of the term falls short in comparison to other disciplines.
For the record, I'm still of the mind that "real" engineers are those individuals trained to create physical things built to withstand innumerable stresses, structural material complexities, manufacturing hurdles, and so forth without endangering lives or risking property damage. We software types have sort of usurped the term, for better or worse. It's here to stay, but some kind of indicated specialization known widely beyond our industry could help.
Regarding "full stack" though, there are areas of certain software-heavy industries where that term doesn't matter. Take an avionics "black box" for instance. It can be a strictly embedded device with no concept of a PC-type environment. They almost universally run some kind of RTOS or compartmentalized RTOS, and perform a short, known list of master tasks (10-20 for instance) that will never change. They talk with various hardware in the aircraft and through radios on the aircraft to a variety of ground stations, satellites, and other aircraft. The standards they adhere to (for the physical wiring from box to box, the protocols on those wires, the way the software is designed, etc.) can be 20-30 years old. Those standards can be updated sometimes never, sometimes 2 or 3 times over that span. There's no concept of constantly changing software libraries because it's so SO ridiculously expensive to go through a process called "certification" that reports on exact versions of software working on exact versions of hardware, and then you don't change a thing (not a single resistor, not a single bit) unless you have a very good reason to. Besides knowing your embedded software/hardware craft, the companies that build these boxes want engineers steeped in the guidance and rules of the appropriate regulating body (in this case, the FAA). There's a rep from your company (but representing the interests of the FAA) looking over your shoulder, so to speak, called a DER. That person's job is to put their ass on the line for your company, to the FAA, saying you did what you were supposed to. You have to highly specialize in order to do your part correctly so your DER can do their highly specialized part correctly, so the FAA can approve your company to sell said black box to aircraft manufacturers with an FAA seal of approval. It's a ridiculously intricate, expensive, and time-consuming process that helps to ensure air travel is generally extremely safe. The FDA is about 20 years behind the FAA in terms of dictating what and how, but similar concerns, processes, and regulatory hurdles apply. There's extreme rigor required in these fields, and extreme specialization, because if you screw up you can kill somebody (or lots of somebodies).
The downside of this is onerous and often poorly done interview processes designed to attempt to assess what the applicant is actually capable of.
Nothing. "Software engineering" is something anyone can attempt to engage in. It seems to conjure up an image of something better than bad programming. But unlike, say, mechanical engineering, there is no professional certification required to call oneself a "software engineer". The fact that this hobby/job is an unregulated practice may have something to do with the ubiquity of bad software. Some of the best programmers, e.g., Arthur whitney, have referred to programming as being like "art". The programmer who started this site in fact wrote a book called "Hackers and Painters".
Besides that, a lot of job titles are arbitrary, made up and not consistent between companies. Call yourself what you think you're qualified to do and want to do. Same if you're freelance or a consultant, because nobody is going to give you a title.
