Ask HN: Can non degree-holder use the title Software Engineer?
35 comments
Why not? In the US, there isn’t a formal professional engineer (P.E.) certification for software engineers (unlike most other branches of engineering). If you’re performing the same job as someone who has a software engineering or comp sci degree and your job title happens to be “software engineer,” why would it matter if you have an unrelated degree, no degree, or even no high school diploma?
*This may not be true outside of the US
*This may not be true outside of the US
In Canada, you can't call yourself an engineer unless you are a P.Eng.
In Texas, the roster lists 60 professional engineers who hold active licenses with “Software” as one of the branches. I expect some of these individuals took and passed the NCEES exam in software engineering, which was offered from 2013 until 2019, when it was discontinued due to low interest:
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.
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.
Non-degreed Software Engineer from the USA here, weighing in with biased opinions:
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.
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.
So, you’ve over thought this a bit. There is a course in comp sci called ‘Software Engineering’, and it’s the place where stuff like UML diagrams and end-to-end testing get covered (differences between tests). The UI developer would need to test his/her stuff too, no? You can engineer a good codebase for anything, not just critical applications.
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?
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?
I understand where you're coming from. I might have come off as a little "this is better than that" unfortunately.
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).
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).
As someone who's worked on consumer electronics (analog + high speed digital PCB design) and software ranging from (research) satellite firmware to an orchestrator for a robotic genetic diagnostics pipeline but now works mostly in frontend/"full stack" roles, I disagree with your characterization of engineering. At it's core, engineering is about wrangling constrained systems to impact the world around you and the people living in it. Corny as that statement is, ounce for ounce, software engineers' sweat go so much further in that regard, for better or worse. The impact is very diffused so its hard to measure and we don't get that new-factory-smell assembled prototype from the fab to hold in our hands, but software has transformed the world around us (in concert with the hardware that runs it, of course) at a staggering pace.
I will say that your description matches what I consider "real" vs "bullshit" engineering - akin to how people refer to "bullshit" jobs. Science is all about discovering the constraints of the physical world and before software, engineering was all about exploiting those constraints to do what we want. Software engineering, however, is unique because its constraints are, more often than not, of our own making. All that time and boilerplate spent managing memory and converting data between all these different formats and representations is our own damn fault, which certainly takes away some of the pride that a mechanical or electrical engineer gets when they trick nature for their own purposes. Software's closest cousin is probably systems engineering and we've massively failed in learning its lessons.
I will say that your description matches what I consider "real" vs "bullshit" engineering - akin to how people refer to "bullshit" jobs. Science is all about discovering the constraints of the physical world and before software, engineering was all about exploiting those constraints to do what we want. Software engineering, however, is unique because its constraints are, more often than not, of our own making. All that time and boilerplate spent managing memory and converting data between all these different formats and representations is our own damn fault, which certainly takes away some of the pride that a mechanical or electrical engineer gets when they trick nature for their own purposes. Software's closest cousin is probably systems engineering and we've massively failed in learning its lessons.
I suppose before I give a thorough response, why compare the apple to the watermelon?
I personally have no clue who the engineers are on this earth that architect a fly-by-wire system. Actually, the complexity and critical nature of it is so beyond developing a UI, that anyone would know the difference.
Now read the last statement above again. Outside of tech, is it truly true that anyone would know the difference? Or are we just ‘IT guys’ to the rest of the world. To fight amongst ourselves over titles, when we ourselves appreciate the differences, can only happen if we are trying to attain external validation.
Case study: Developer A: I am a software engineer at Facebook
Developer B: I am a software engineer at Boeing
Developer A: Billions use my software
Developer B: People die when I make bugs
The problem is not that Developer A and B don’t understand or appreciate the difference. The problem is the rest of the world doesn’t, therefore the industry has zero status. I’m arguing we are manifesting a frustration internally amongst ourselves from the greater sin of lack of respect given to us from outside.
Which brings me to my final point. If there is internal resentment, that a Facebook engineer makes more than a Boeing engineer, then we failed as an industry in not compensating appropriately. If the manifestation is from unfairness, we should examine that. If the Surgeon gets paid less or the same as the Podiatrist, and is resentful and bitter, we need not turn a million stones to find the crux of the matter. And, suddenly, the surgeon yells ‘that foot doctor can’t hold a scalpel if their life depended on it’. Lamentations of a deeper problem amongst ourselves.
All emotions are valid here, as the injustice is consistent and real. For most part, I am trying to distill the dialectal argument into it’s rhetorical form.
I personally have no clue who the engineers are on this earth that architect a fly-by-wire system. Actually, the complexity and critical nature of it is so beyond developing a UI, that anyone would know the difference.
Now read the last statement above again. Outside of tech, is it truly true that anyone would know the difference? Or are we just ‘IT guys’ to the rest of the world. To fight amongst ourselves over titles, when we ourselves appreciate the differences, can only happen if we are trying to attain external validation.
Case study: Developer A: I am a software engineer at Facebook
Developer B: I am a software engineer at Boeing
Developer A: Billions use my software
Developer B: People die when I make bugs
The problem is not that Developer A and B don’t understand or appreciate the difference. The problem is the rest of the world doesn’t, therefore the industry has zero status. I’m arguing we are manifesting a frustration internally amongst ourselves from the greater sin of lack of respect given to us from outside.
Which brings me to my final point. If there is internal resentment, that a Facebook engineer makes more than a Boeing engineer, then we failed as an industry in not compensating appropriately. If the manifestation is from unfairness, we should examine that. If the Surgeon gets paid less or the same as the Podiatrist, and is resentful and bitter, we need not turn a million stones to find the crux of the matter. And, suddenly, the surgeon yells ‘that foot doctor can’t hold a scalpel if their life depended on it’. Lamentations of a deeper problem amongst ourselves.
All emotions are valid here, as the injustice is consistent and real. For most part, I am trying to distill the dialectal argument into it’s rhetorical form.
I see I must be coming off as more of a grump than I anticipated :) I don't personally harbor resentment over different applications of our industry, but in fact am steadily amazed (befuddled/astounded). The market is what it is, and we individuals are fairly carried along like so much flotsam on the waves.
I agree we're perhaps dickering over distinctions no one external cares about, akin to characters in "Let That Be Your Last Battlefield". Is our internal perspective as valueless as the mindset of those characters above, or is there use in hammering out a common understanding for the general public before it's handed to us?
That being asked, the distinctions may be moot. Most of us have probably 10-20 years of rapidly dwindling utility in our respective realms due to the swift boot that is ML/DL/etc. And your point will remain more poignant at that time: "will anyone outside of our field know or care about the difference?".
I agree we're perhaps dickering over distinctions no one external cares about, akin to characters in "Let That Be Your Last Battlefield". Is our internal perspective as valueless as the mindset of those characters above, or is there use in hammering out a common understanding for the general public before it's handed to us?
That being asked, the distinctions may be moot. Most of us have probably 10-20 years of rapidly dwindling utility in our respective realms due to the swift boot that is ML/DL/etc. And your point will remain more poignant at that time: "will anyone outside of our field know or care about the difference?".
[deleted]
In Canada the title "Engineer" is protected by law. One must have an engineering degree from an accredited university in order to use the title. It's fairly strictly enforced.
That's not entirely right. You need to be licensed by the provincial engineering body to call yourself a P.Eng. An engineering degree from an accredited program is often part of the path to that credential, but is neither necessary nor sufficient by itself.
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.
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.
Same with Architect. It's use in software is completely unregulated compared to Registered Architect (the equivalent to P.Eng).
Not that strictly enforced. None of the job requirements will ask for PEng.
https://ca.indeed.com/jobs?q=software+engineer&l=Toronto%2C+...
https://ca.indeed.com/jobs?q=software+engineer&l=Toronto%2C+...
I think Texas also does or did. I think there was a push to repeal that law since it wasn't really enforced, but I don't remember if it was successful.
"I am interested to know, apart from learning to program and developing/designing software solutions, what makes a software engineer an 'engineer'."
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".
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".
I think you are asking a legal question? I am not a lawyer, but I can say that some governments in some countries require specific certifications in order to hold certain titles for certain government jobs. Otherwise the answer is yes, you can have whatever title you want provided that title does not imply any legal requirements doctor, lawyer. Your CV and interview with a business will help them determine if you meet the definition of your title. I have phone screened people that listed themselves as Sr/Principal ______ engineer and they could barely Google any of the answers. They won't get in trouble but they also won't get hired.
I have a software engineering degree and I don't think you should call yourself a software engineer until you've actually worked in that capacity on actual projects for a while. You could ace the degree but not have the experience to deliver real projects until you have practice.
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.
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.
Tbh. I think when people see Software Engineer and Developer on a job ad or a CV, both mean the same thing to them. I certainly see as many job postings using both titles interspersedly.
Depends on what legal jurisdiction you work in. In the United States, job titles in the software industry are neither standardized nor enforced by any organization so people are free to call themselves whatever they like, regardless of education, experience, or even ability.
The downside of this is onerous and often poorly done interview processes designed to attempt to assess what the applicant is actually capable of.
The downside of this is onerous and often poorly done interview processes designed to attempt to assess what the applicant is actually capable of.
The upside is that it reduces the gatekeeping that so many degree-holders would like to have in place.
There's little to no regulation around the term. You'll find job postings for "junior software engineers" that need very little experience. Bootcamps use "software engineering" in their marketing, so I presume graduates call themselves that when they finish (even though at that point, they're qualified for little more than apprenticeship roles)
An academic degree is not a professional license. Software has no professional licensing so call yourself any title you want.
Yes, if you get hired for a job with the title software engineer, you are one. There are no education requirements for this. Same with any other title in tech. The distinction between developer and engineer doesn't really exist - engineer just sounds a bit fancier so some people prefer it over developer.
In some countries, yes. Either way developer is a better term than engineer when it comes to software imo.
Not in the US. In some european countries the title “engineer” is indeed protected by law.
That's been my job title for two or three decades. It wasn't a title that I chose for myself. Now, though, I use it for myself because that's the way others describe my role.
This was my title at my last job. It's just the title for coders. Nothing more. I think it's a bit pretentious personally, so I usually just say programmer.
Question, what do you want to use it for? If it’s somewhere like LinkedIn, nothing can stop you.
My question was like more geared towards - what makes a Software Engineer, a Software Engineer. is it the Software Engg. Degree, practice, or some other characteristic traits that one has to demonstrate in order to become an Engineer.
That depends on what you think the title of software engineer means. If you think of it as meaningless, then there are no requirements. If you think that the title of software engineer should be like the professionally licensed engineering fields, then look at what the requirements for professional recognition or licensing in those fields are. Usually its agreeing to abide by a code of ethics, proving that you possess understanding of the fundamentals of your field (either through education or learned on your own), demonstrating your competence though a number of years of working experience, and demonstrating that you're keeping up to date with changes in your profession (the continuing education requirement).
Tech companies in the US have definitely hired non-CS majors (Computer Engineering, Math) from my college for Software Engineering roles.
you can use absolutely any title. you have to be able to justify the skills.
Just plain YES.
Nowadays, you can identify as whatever you want.
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?