Some engineering fields have all those things you describe but it is usually because there is a high degree of physical risk to the public, like structural engineers for example.
Mechanical and Electrical engineers, for example, at most companies are hired without any such certifications, unions, oversight, or any of what you've mentioned. I have a degree in EE and CS and have worked in both fields doing everything from IC design to app development and the hiring process, oversight, etc has been the same in almost every case - no membership or union required. I have friends who work as ME, Chemists, physicists, etc and the same is true for all of them except in the exceptional cases where they are working on a medical device or something.
Really all those things you mention at most companies for most fields of engineering come down the the company culture itself and the technical leadership at those companies.
The really funny thing about your take is that in most cases I find that high level software developers have a much stronger cult of engineering excellence that any of those other fields. If you saw the "process" most EE's used to ensure high quality engineering at large companies like Intel you would be horrified. And definitely don't ask those EE guys to write any code, it will almost certainly be terrible.
Yeah, don't do this in Canada, or the professional engineers association can come after you. Only certified members of an engineers professional association can use the title.
To be clear, it is illegal, for example, to pass around business cards that say 'Software Engineer' if you're not certified.
As an amusing example, in the province of Ontario, people with the Microsoft Certified Systems Engineer certification are allowed to use the title 'MCSE', but not its expansion, because it contains the word 'Engineer'.
However, you are always allowed to state your degree, so you can say, {name}, B. Eng., or M. Eng., as the case may be.
*At least, in Quebec and Ontario - the legislation is province-scoped, I assume other provinces are similar.
Coming from a US perspective, I feel like "engineer" on its own is a descriptive word. "Professional Engineer" is a trademarked title, and that seems reasonable. Do I have certification as a PE? No. Do I think it's reasonable to describe what I do as software engineering? Yes. To me, it implies that I take part in planning, designing, implementing, supporting, and retiring software. "Programmer" connotes that I took someone else's design, wrote to that spec, and handed the results off to someone else, rather than taking part in the entire lifecycle.
It's not a requirement for ME and EE, but it is a universally recognized certification. PE-licensed engineers often enjoy better employment prospects.
(FYI, there is PE exam for software. The difference is: it's not widely know in the industry.)
I tried to see if there was an opportunity for an engineering mentor at my job (One of the big four) and I was unable to get anywhere. It seems that it is better for our job prospects to get a job at a prestigious/interesting company and gain experience there than try to go through the licensing process.
Directly from wikipedia: In 1960, the Conference of Engineering Societies of Western Europe and the United States of America defined "professional engineer" as follows:
A professional engineer is competent by virtue of his/her fundamental education and training to apply the scientific method and outlook to the analysis and solution of engineering problems. He/she is able to assume personal responsibility for the development and application of engineering science and knowledge, notably in research, design, construction, manufacturing, superintending, managing and in the education of the engineer. His/her work is predominantly intellectual and varied and not of a routine mental or physical character. It requires the exercise of original thought and judgement and the ability to supervise the technical and administrative work of others. His/her education will have been such as to make him/her capable of closely and continuously following progress in his/her branch of engineering science by consulting newly published works on a worldwide basis, assimilating such information and applying it independently. He/she is thus placed in a position to make contributions to the development of engineering science or its applications. His/her education and training will have been such that he/she will have acquired a broad and general appreciation of the engineering sciences as well as thorough insight into the special features of his/her own branch. In due time he/she will be able to give authoritative technical advice and to assume responsibility for the direction of important tasks in his/her branch.
I don't see anything about unions in there
Basically, what defines a "real engineer" has pretty much nothing to do with engineering? I'd rather define engineers as people who have the skill and know how to engineer.
Why do I keep seeing people comment without reading the article at all...
Programmers have a lot of engineering work supporting them in different ways and sometimes they do actual computational engineering. I don't have a problem with calling myself a programmer. Patrick M does because he wants to translate his work into the language of corporate and marketing communication because he thinks this will make him more valuable. I'm not sure that's a good strategy except to create a kind of odd cloud around what he's doing. Programming is not so mysterious to management anymore. They know it's valuable. Those that don't, well, I'm not sure you want to work for them anyway.
I hate being called a programmer, am okay with developer, and call(ed) myself a software engineer, and that's why my title said as well. I wasn't the director of programming, and I wasn't running a team of programmers. I ran the software engineering team and I hired software engineers.
In my mind, they're not interchangeable terms and have specific meanings. A programmer is someone who can write code, cobble together applications in a generally slapdash fashion, and does not apply a lot of creativity or thought to the how's and why's of what they are doing. They are the front end web dev who can't write pure JavaScript and have to use jQuery and a bajillion other includes just because they don't know how or care about the implications.
A developer pays some attention and care, has a reason why they may have made certain decisions, and is generally thoughtful about their core areas of knowledge. Maybe they're not as thorough, have a more narrow window of experience, or generally don't care about 'those other things' like networking, operating systems, protocols, etc.
A software engineer knows about OSI, the types of protocols in use by their application, the pros and cons of various libraries, and has a reason that can be backed up with at least some empirical evidence for any of the choices they make. They step back and look at the problem they're solving as a whole instead of piecemeal, and they're generally not shortsighted. They apply rigor, experience, and research to all phases of what they're working on.
We were all programmers and developers, some of us get to software engineers if we want- but it's really about the rigor and discipline you apply to your craft.
I agree that the fundamental aspect is the accountability, however unions don't mean anything for the quality of your work, and there are ways to certify specific areas of knowledge already.
You must be a C/C++ guy :)
What would you put in software certification? If you focus on high-end CompSci stuff, it won't be relevant for the 99% who spend their careers building CRUD apps. If you focus on tools, it will be out of date by the time the exam papers are off the printing press.
I agree that there could be industry certification on topics like security and perhaps accessibility. But on everything else, the answers depend on so many factors, they can't be certified in a meaningful way.
Also, some of the best software engineers I know don't have certification because they struggle with exams. The ability to pass an exam doesn't make you a better engineer.
Certification is nice in theory, but in practice would probably lead to worse results.
I call myself a software engineer because it's what managers call me. As long as I don't claim to be able to build a bridge across the River Thames, I don't see the problem.
As a "guy who writes code" - call me whatever you want, i could probably give myself a fancy title and get away with it, but I am one of the very successful (When compared to the 99%) people who didn't finish school but managed to get by in the tech industry very comfortably. Life is already great, perhaps I just don't deserve to get everything my way.
I don't use "software engineer" as an ego thing, but because it communicates better the variety of knowledge I have to people that barely understand how to turn their computer on. I get better pay, my employer is happy, everybody wins.
It's to give the world hard proof that you actually UNDERSTAND what is happening and allows you to actually accept responsibility to create things that may actually affect peoples lives. Sure its useless if all you do is work on a react/angular app, but not all software is your standard CRUD app.
But there's no clear line where an app stops being CRUD and starts being something more, so there's no clear line where you stop needing a CRUD programmer and start needing a software engineer.
There are some that clearly need certification, and often that is an explicit requirement of the job.
Just don't get too hung up on the job title. Managers want to believe their software is so complicated that they need a software engineer to build it. I'm happy to go along with their delusions if they pay me.
Really, the ideal system is self serving. You create a framework of professionals that self-govern. The Professionals appointed/elected to the governing body are responsible for ensuring the certification is relevant to the profession. I somewhat prefer the mentorship program over testing individuals on knowledge in their domain because your mentor(s) will be a better judge that you're understanding concepts, regulations, rules, and needs better than any exam will test for. Like you said, knowledge that I apply on my career is very different from knowledge you apply in yours.
Another thing that I want to say though is that I don't feel certification is necessary in software unless you're in a position that carries potential harm to a person's safety/wellbeing. There's a few exceptions to what that entails exactly but that's not really the point of this discussion. Generally speaking, I don't want someone with a layman's understanding of code to be programming things where a person can lose their life due to an oversight. In the same way that Professional Engineers in Civil, Mechanical, etc. use their professional seal to say that "my specs meet all relevant modern standards of safety/design/etc", I want software engineers programming that medical device or safety equipment have the same accountability. Currently there isn't an international recognition of "Software Engineer" as a title to say who is working on that device has been vouched for professionally.
There is a difference here in that someone working on a medical device isn't directly offering their services to the public, and the work-product is subject to external testing and oversight.
Hm... ok, I'm not sure I buy that. How are you defining "best"? I suppose I can accept that there may be a handful of people (worldwide) who can produce amazing software but are somehow unable to memorize and regurgitate facts, in the same sense that there are people in the world who can recite all the digits of pi but can't tie their own shoelaces - but I have a hard time believing that such people are very, very rare.
Engineer is not a guy putting things together on an assembly line. Engineer needs to understand things that are base for his/her field.
> If you focus on tools, it will be out of date by the time the exam papers are off the printing press.
My tools that are dozen years old work just fine, thank you very much. And they work faster, more transparently, and more reliably than most of modern buzz, if we're at that.
2014: 6 people took the test and 2 passed.
2015: 5 people took the test and 2 passed.
2016: 3 people took the test and 2 passed.
Only California has more programmers than Texas, see [2], and it appears that there are 6 Professional Engineers at most in Texas in the field of Software Engineering out of over 20,000 programmers.
My conclusion is that the title of PE in Software Engineering is currently pretty meaningless in the US.
* Demand, since it is a new exam very few companies will be looking for a PE in software engineering.
* Supply, it's not just taking the test (starting with the FE) but you also need to have worked under a PE in the field (hah!) or had relevant experience to waive that requirement (this is a lot more vague and determined by the state). I would wager that most with relevant experience in the field are also not wanting to bust ass to study for a PE exam that no employers are demanding.
I'll be interested to see how long it takes for this to be more common. When I graduated (computer engineering) the consensus was that unless we knew our job would require a PE in the future that we didn't bother even taking the FE exam.
> ABET (the engineering accreditation society in the US), doesn't have "Software Engineering" as a valid discipline.
Which can be true or false independently of how meaningful the title is.
I see nothing wrong with someone calling themselves a software engineer that has both training (a CS degree for example) and experience (a few years) working in software development.
No, it's like professional soccer teams saying "I won't hire anybody who the USSF didn't say is a 'soccer player' because they have a good track record of establishing credentials and I trust their judgment".
[0] and probably also offering "engineering" services but I'm not sure of the extent there
That's literally my job right now. If I could claim the title of Doctor I'd totally be for certification (but for purely, very selfish reasons).
In addition to the points you make, real certification (as opposed to a four year degree, which anyone willing to go into debt can get) would simplify interviewing and reduce the "whiteboard hazing" and "throw darts at a dart board" methods we use today for finding good candidates. Organization would help fight for a proper career path for programmers, rather than having to, as an individual, constantly negotiate and hop from one employer to another in order to advance.
Well, I admire your optimism, and as much as I wish there were professional licensing for software professionals, I doubt that any licensing exam could ever be so rigorous that at least a few charlatans wouldn't be able to squeak through it.
> would simplify interviewing and reduce the "whiteboard hazing"
I doubt it. If a certification is too specific it'll exclude an enormous amount of engineers. Make it too broad and then companies will still have to do the same interviews they do now to verify that a person is a good fit for the specific job opening they want to fill.
I'm eager to hear your proposal on a certification method that doesn't exclude wide swaths of existing and future engineers based on your specific definition of what a software engineer is and isn't, but at the same time is specific enough that having the certification actually means something to other people.
Most likely it is because a great many programmers without a formal college education or with a non-CS college education think that certification might be used to demote them to second-class citizens. And, without commenting on the rightness or wrongness of it, they wouldn't necessarily be incorrect about that either; such an exam would most likely have a strong focus on CS topics.
I'm pretty sure that's not true, and in fact one of the distinctions about a professional is that he doesn't belong to a union: he is both worker and management.
Plus it's baked into the title of "the Art of Computer Programming" by Donald Knuth. How many people can really say they have mastered that art? It's hard to believe there's any qualification more worth striving for or harder to achieve.
That's great if things work that way in other countries. But in the States, things work differently (in the software industry, at least). And like it or not, are unlikely to change (any more than this country is likely to shift over to the metric system) anytime soon.
And unfortunately the term "programmer", as a resume heading, has come to be laden with negative baggage in various ways (as detailed in the original article). So in practical terms, you are 1000% better off calling yourself an engineer or developer (rather than a "programmer") in the U.S. at least.
my response to this is simple: do you think that words matter? If so, which word do you think is most effective in communicating with people outside of the field?
there's room for people to come up with radically different answers to those questions, but my answer is that "Software Engineer" matters when communicating with non-programmers. When talking shop with a fellow practicioner it doesn't matter much what word you use. This is just about communication with the outside.
Real engineers have certification: you know, that thing that indicates that you can actually do your job worth a damn. What do programmers say whenever the topic of industry certification is brought up? Usually, furious opposition.
Real engineers have accountability: engineers in a lot of other industries can be civilly or even criminally liable if their broken shit hurts somebody. What do programmers say whenever the topic of accountability for broken software is brought up? Usually, furious opposition.
Real engineers have unions. You know, that thing that keeps your labor from being exploited by-- just to give some hypothetical examples-- intentionally confusing and exploitative equity renumerance, or floods of H1-B workers. I shouldn't even have to tell you what the attitude towards most programmers is to unions, at least in America.
And whenever the topic of certification, or accountability, or unions, is brought up in the context of our discipline, the response is almost invariably, "Well, it's different for us, because $REASONS". Okay, fine, it's different for us, but then we shouldn't call ourselves engineers, because it's clearly a category error.