Some countries (Canada I think being one?) may require you be licensed/registered with an engineering body before you're allowed to call yourself an engineer, but thats not the case in most countries AFAIK
Then I started working for an American company that was like shrug no laws against that.
I just can’t say professional engineer.
The whole thing makes a ton of sense when we’re building bridges or airplane safety rated computer systems, but not so much when building websites or whatnot.
There is overlap, but they are not identical skillsets.
Analysts are certainly developers, but engineering involves more of a sense of scalability, analysis can do this, but it is generally more granular.
https://ncees.org/ncees-discontinuing-pe-software-engineerin...
Examples: measuring data scale for growth rate and future needs, calculating incremental costs of cloud instances and data stores, designing and proving a state machine, instrumenting systems, measuring and stress testing a system against load, understanding back pressure and dynamical behaviors of distributed systems, designing threaded or active/active systems, vector clocks, consensus algoritms, test suites, etc. etc.
I've had to write short inductive proofs in several of the systems I've built.
It's engineering. The sooner we get over the imposter syndrome debate of what we can and cannot call ourselves and embrace the full scope and possibilty of what we can achieve, the sooner we can become better and more capable software engineers.
In what context was this necessary?
What I think are the relevant extracts from the article:
> “Do you consider software engineering actually engineering?”
> Of the 17 crossovers I talked to, 15 said yes.
> That said, many of the crossovers [3] also added an additional qualification: software engineering is real engineering, but a lot of people who write software aren’t doing software engineering. This is not a problem with them, rather a problem with our field: we don’t have a rich enough vocabulary to talk about what these developers do.
The engineering field has developed a vocabulary for different professionals in the field. Why can't this be applied to the software field since it is a form of engineering? There are engineers, technologists, technicians, and trades (at least where I am). The issue is there are education and work experience requirements that lead to licensing, which people will say are inequitable and gatekeeping [4]. From 2, there was an experience-only path available to get software engineering licensure, so if the field really wants it, there seems to be precedent to allow for alternative routes into those titles.
[1] https://ncees.org/engineering/pe/software/
[2] https://www.nspe.org/resources/pe-magazine/may-2018/ncees-en...
[3] The definition of "crossovers:" "people who used to be professional engineers and then became professional software developers. I call these people crossovers, hybrids between the two worlds."
[4] I'm sympathetic to these concerns. I studied engineering technology and worked as a technologist at the beginning of my career. I wanted to become a mechanical engineer, but I couldn't afford to return to school full time to complete the remaining 2 years for the BEng. (My school offered a 2 year diploma for engineering technologists, which led directly to years 3 and 4 year of the BEng.) When I wanted to complete the degree, a full time course load was required (7 courses per term at my school) for the engineering program to maintain accreditation.
On a spectrum, there are software developers that follow the engineering design process and use all sorts of knowledge of applied science, but there are also those who make it all up as they go along and rediscover or rename concepts independently. Each approach comes with its own associated benefits and tradeoffs, and there are times and places where the latter end of the spectrum can be desirable.
At least that's my hot take.
[1] https://www.mcgill.ca/engineeringdesign/step-step-design-pro...
Let the downvotes commence.
Edit: This is a gentle ribbing, but there really does seem to be a different approach in the philosophy of how to solve a problem. Engineers seem to eschew abstraction while software folks embrace is (sometimes to a fault). It's actually pretty fascinating.
Actually this is one thing that has always confused me about “software engineers,” at least as someone with an engineering education who isn’t doing engineering work really: we learned how to do particular types of problems very well and reliably, and generally learned a bunch of math tricks. But at a fundamental level the material that the physics students were learning was basically more complicated. Scientist has always felt like a more prestigious title to me. Since most programmers have computer science degrees, why don’t we call ourselves computer scientists?
Because they aren’t doing scientific research, they are applying the products of such research to design (and build; with software the distinction is less significant than with many physical items) products, so its somewhere between architecture/engineering and constructiom, rather than science.
Of course, you can do too much abstraction.