I’m just as surprised to see the number be this high. I can’t help but wonder if this might be due to survivorship bias: crossovers are, after all, self-selecting. Perhaps not all engineers would say the same, if forced to swap roles.
Regardless, I’m excited to hear more from these crossovers. As a (soon-to-be) recent graduate, I think there can tend to be a great difference in perception between CS students and Engineering students, particularly at institutions without rigorous CS programs. Many tend to view CS students in the same way that some CS students view bootcamp students- people motivated by an “easy path to success”. I’ve found this opinion is rarely held of engineering students, given the reputation of engineering programs. I think it’s very useful to profile the motivators, mindsets, and general attitudes between the disciplines, if only to see that perhaps the difference isn’t as large as one might assume.
MechE here so my thoughts can be biased. It’s high because of two reasons. One the pay is typically much better (upward of 20%-100% (yes 100) better) and secondly the “crossover” barrier is much lower compared to other engineer mobility. For instance I would argue, a MechE becoming a SWE is easier than a SWE to become a MechE since companies are opened to SWE not having a specific degree in it.
I wonder if there might be a technological barrier. My degree is in physics, so I depend on mobility for any hope of employment. ;-)
It was easy to learn programming. One reason was that the tools were always relatively cheap (even when they cost money), and the cost to learn by trial and error was negligible. At least this is true for the basics. Becoming a good programmer who can be an asset to a large project is outside my wheel house, though I'm in the process of learning.
Today, for mechanical design, you at least need access to SolidWorks, and the part of learning that comes from experiencing failure is costly and time consuming. Surely 3d printing is changing that equation, but not overnight.
But you can test the waters of programming without asking anybody for permission, and if you discover that you hate it, then you can just bury it. And many do. Programming is hard or most people, for reasons that I don't think we understand.
Now, programming and mechanical design by themselves are not engineering, but if someone wants to get into a new skill through the back door, they are similar. A person with SolidWorks skills can be useful as a designer without being a full blown engineer.
The answer is a clear yes in my case, but I work on commercial numerical design and analysis software. The interleaving of computers and engineering entailed here makes a hard case that there is not an absolute "no" available. But computational software is a corner case, I know. (sigh)
We certainly view our pure CS people as experts in what they do -- and the things I see them do are, e.g., build out cloud based versions of our product, add new GUI features, automate build and test systems (until management tries to replace them with us... a dubious proposition at best). That's just the stuff I see day to day, since it's most closely tied with us on the numerical side. Why wouldn't that be engineering? I could speculate but I don't care to. We are all working to make the product the customers want.
I have a degree in Software Engineering and NOT CS. I had to teach myself a lot of core CS, largely for interviewing in the industry which is full of CS majors and people with myriad unrelated degrees (or no degrees).
You can't call yourselves 'hackers' and 'engineers' at the same time. (I mean, you _can_, but talk is cheap)
That's not a bad thing by a long shot. There's a time and place for hacking as there is for engineering.
My own personal views (electrical engineer who deals a lot with software and who codes a lot) are that you can find people that can do engineering work without an engineering degree today. A lot of that stems from powerful software that abstracts away much of the math. So you can load a model into a vendor's product and run transmission load flows without much formal training. However, if you haven't taken any circuit classes, complex power, calculus...etc, you're never going to truly understand the results of what you're doing and the end results will suffer in quality. That's why engineers are generally hired (assuming a PE license isn't required) instead of anyone with a 4 year degree. Before computers, a lot of that would be done by hand (at least the calculations that were feasible at that time) and you would pretty much have to have gone through an engineering, physics, or math program to have those kinds of chops.
Software is different in a lot of ways. Especially at the high level, you are solving a puzzle. Let's say you need to generate a report. You've got all the tools in your language and several libraries. You know you'll have to talk to a database, pull down data into some kind of data structure, open a file handle, write the data, close the file, and save the results somewhere and then send an email. Is it technical? Yes. Challenging, well...maybe not this example, but software can be very challenging yes. But is it engineering? I wouldn't call it that. And no, I'm not sneering at it, or calling engineering superior. I just see the two as very different.
The stuff you do in engineering school (calculus, differential equations, statistics, linear algebra, circuit analysis, signal processing, Fourier transforms, control theory...etc as tools to solve problems with radio, industrial machines, turbines..etc) has pretty much zero to do with web design, standard business apps, databases, compilers...etc. If you use engineering as a general term to mean "make technical stuff" than you could apply it to either field equally, but engineering has already had a definition for many years and software is it's own thing. So use the term "coder", "developer", "programmer", "hacker", "complexity guru", or even "software engineer" as they all make sense. But the general term "engineer" would apply to mechanical, electrical, chemical, industrial, civil, biomedical...etc. All of those fields have the same core math classes and they then usually share an intermediate set of classes (thermodynamics, dynamics, statics, circuits...etc) before the advanced classes which specifically apply to your field. I don't think a very high percentage of coders (amazing, technical, often better paid, and very valuable as they are) have an overlapping lineage and language with what you would think of as traditional engineering. Believe me when I say I'm not gatekeeping the term either. I just honestly feel like there these things are taxonomically different. Maybe a new single word term should exist to convey what software developer does with two words.
The enduring popularity of this question baffles me. I get it: other people like other things. But is it an idle enjoyment or is it something that helps conclude other things?
It helps clarify to what standards software is supposed to adhere. As the author points out, the key feature of engineering is building to specification. Engineers have formal processes, standards, fault tolerances and expectations.
The people who write software for a space-shuttle do engineering work, your average app store app is likely not 'engineered'.
I think it matters because it says a lot about how seriously the software industry as a whole takes the quality of its products and to what standards we hold software and with what goals in mind we make software. If we treated software like engineers treat aircrafts we'd likely have a lot less of it, but what we had would probably not crash that often.
The debate is tied to the debate about why so much software today feels so terrible and bloated and that makes it relatively important in my opinion.
The definition of engineer is "a person who designs, builds, or maintains engines, machines, or public works."
We're building software engines, machines, and public works. Just because we're applying it for the software incarnation of the concept doesn't break the definition.
How isn't that like claiming you're a chef because you have a catering company where you serve microwaved foods, and claim it's silly to try to distinguish degrees of cooking skills.
It may be an important question because answering it requires dissecting the similarities and differences between software development and the jobs that people usually call "engineering".
In doing so, we see what lessons there are to take from each other, and gain a better understanding of both fields. For example, the author cites that version control is an innovation that traditional engineering could hugely benefit from.
Why does every person who pulls out a dictionary use a definition that looks like it came from a century old dictionary? Words change meaning over time. There were computers a century ago.
By the definition you gave, no one can be a chemical, industrial, or electronic engineer. Silly!
I think the difference between craft and engineering is whether the knowledge is systematized (not binary, but on a continuum).
Can decisions be motivated by clear objectives and rigorous deductive reasoning, which are useful to validate the design process and also to clearly communicate what is being done and why?
A lot of conventional software “knowledge” is too hand-wavy & wooly (not to mention fad-driven) to pass that threshold, imho. A lot of software platforms/infrastructure we use is the way it is for fairly arbitrary historical reasons, quite apart from the fact that many domains where software is applied are quite hard to parametrize rigorously. There are islands however, where the design is fairly rigorous and could be considered closer to the spirit of “engineering”. But the most important input for a craft to mature into engineering is time and rigorous effort.
Either ways, I don’t see this question mattering too much in immediate practice.
I have seen that a lot of people that now have "software engineering" titles that are not doing "engineering of software". They're doing network/platform management or some other task that doesn't involve the actual design and architecture of software systems. ie. it's more of a payscale for HR than an actual discipline
Engineers should be able to understand design principles and be able to architect a new system from those principles. In today's world i think we are moving further away from this than closer. We spend much of our time learning trivia such as how to fiddle with a particular software platform to get it to work.
Additionally with all the various abstractions that we have built (lock-in cloud services, high level languages, proprietary platforms, etc) many people are no longer capable of discussing with you what is happening on the CPU or how data should flow through a system or the disadvantages of a distributed architecture, etc.
I think that software engineering is still in it's infancy in someways and hasn't yet matured enough to be an engineering discipline. That being said there is an egalitarian quality about being a "software engineer". We're all software engineers.
There is something special about software engineering that deserves a bit of thought - the discipline is all of 70-80* years old. There are people on HN who are older than software engineering.
Engineering is very much about the accumulation of experience - the reason all the planning is up front isn't because the Secret Society of Engineers said so, but because they are practicing something that has between hundreds (electrical, maybe ~200 years) and thousands (mining, dates back to the stone age) of years experience.
In 100 years, software engineers will have an enormous advantage over almost all non-engineers at designing and running software projects. There'll be a few amateur prodigies that nobody trusts, and putting an engineer in charge of software projects will mysteriously trigger a lack of things going wrong.
Software isn't unpredictable. Nearly nothing is unpredictable. The process of figuring out which bits are predictable isn't finished because the hardware keeps changing and forcing the tech stack to change. When the S-curve of hardware progress flattens, software engineering will gain in importance.
* Changed from 20-30 because that was wrong. Changes none of the arguments.
"The Mythical Man Month" first edition is 45 years old as a retrospective on a decade old development project 55 years ago.
The strongest indication programming is not engineering is forgetting and reinventing the past. Also revolutionary tools and techniques are invented far too often in CS.
In mechanical engineering we've had screws for a few centuries and off the top of my head the most recent innovation in screw fastener tech was the creation of the "Torx" screw standard in the 60s. The Torx innovation was due to smarter torque controlled automatic screwdrivers on assembly lines WRT electronic drive tech and early digital control.
While the basics principles are the same and over 120 years old, the Combustion engine has been re-invented and re-engineered a gazillion of times...
Maybe some of you guys here are young, but there were cars (large SUVs, or Sports Cars), that would consume 8-9mpg, yet still be slow as molasses compared to today's cars.
So, yes while the basic principles of the combustion engine are the same... but it has been re-engineered (from scratch), a many times, and each time it would be slightly better and better.
Additionally, the process of doing the physical engineering has changed drastically -- computational tools, design space exploration, optimization methods. (recognizing that the grandparent comment stuck specifically to screw-tech, but it's interesting to think about physical-engineering-innovation in broad terms)
Then there are innovations in manufacturing enabling new designs. 3D printing is coming along. Not everybody has to pull from a catalog of shapes, thicknesses, etc, for structural design.
You are right that software engineering is a relatively young field, but people have tried to apply engineering principles to software since at least the Fifties. The term itself was coined sometime in the early 60s and was used by the ACM in 1966.
How do you define software engineering such that it's 20-30 years old? Why isn't it 50 years old? I ask because I've heard the argument that software engineering is a young discipline but it feels like you're really stretching it with those 20-30 years.
>When the S-curve of hardware progress flattens, software engineering will gain in importance.
But a lot of software engineering issues are entirely divorced from the underlying hardware. So I'm not sure how the shape of hardware has any significant bearing to our current situation.
>Engineering is very much about the accumulation of experience
I would argue that we actually know a ton about how to build software. It's just that it's not really being taught or valued or applied. I would argue that's an important distinction because it strengthens the analogy of electrical engineer vs electrician. So it's more about just an accumulation of experience.
> But a lot of software engineering issues are entirely divorced from the underlying hardware. So I'm not sure how the shape of hardware has any significant bearing to our current situation.
To play devil's advocate with the other's position, even just over the time I've been in software since the early/mid 2000s I've seen things shift a number of times as new hardware creates new demands from our software or obsoletes old development struggles. PC RAM capacities rising 100x from 20+ years ago, more operations coming over on a slow and flaky WAN from untrusted devices, fewer people tolerating apps that only work on the tower PC stuck on their desk, more apps expected to sync state across devices because they're cheap enough we can own a bunch of them, use cases we learned to handle with plugged-in tower PCs adapting to power-draw-sensitive mobile devices, mobile devices being 1.5GHz instead of 16HMz, CPUs becoming fast enough that performance is often a footnote concern for whether to implement crypto, dedicated AI microchips changing what's possible on-device...
All of these seem like very reasonable justifications to rethink the way we build software, to change what's standard practice or to invent new tools that solve old problems in a modern context. To some degree the clock on when our industry starts accumulating stable knowledge won't start ticking until these kinds of changes stop happening.
>All of these seem like very reasonable justifications to rethink the way we build software, to change what's standard practice or to invent new tools that solve old problems in a modern context. To some degree the clock on when our industry starts accumulating stable knowledge won't start ticking until these kinds of changes stop happening.
But we already have stable knowledge that's simply not considered valuable. Your list of changes over the decades is of course a change but I don't understand why the attitude is "unless things stay stable over the next 30 years, there's no point in trying".
All those SOLID, agile, TDD, DDD, micro-services memes that are being implemented so superficially and cargo-cultishly are actually grounded in a real understanding that has a context, constraints, and trade-offs. The issue is that superficial and cargo-cult application. "Software engineers" that decide they're going to do micro-services without understanding what it solves, how it solves it and what they're trading off. And a business that doesn't care or know enough to ask for better. Maybe they don't need better! Maybe it's ok to slap together and the product will be equally mediocre whether the devs use cargo-cult pattern X or not. Maybe the quality doesn't matter that much to the business. In which case the devs being hired also don't need to actually know that much software engineering. In which case maybe the idea of electrical engineer vs electrician makes sense here too.
I think this question always poses something about status insecurity as the old discussion of what makes a "true" software developer.
Engineering and Software Development share a key characteristic which is about inventing and implementing things.
The key difference is that engineering is fundamentally based on applied physics and math where software development doesn't care about physics because it's an already solved abstraction in this discipline.
I think you're right about the underlying concern about status. My sense is that people in this discussion are really asking whether software engineering is just easier than mechanical or chemical or aerospace--or whatever--engineering. That's also why I don't think calls for certification standards really address this concern (you can just as well be certified to do something easy).
the absurdity of the question becomes clearer if you start thinking about the right tool for the job. if you need to invent facebook you don't start with reinventing the wheel but with applying software development. it's the right abstraction for the job. and no sane mind would claim that serving content to billion users a day is an easy task but in the end it's just software.
Not sure if this is hyperbole, but usually bugs are caught elsewhere in the design spiral. If caught early enough, this results in a chewing out at worst (I had a bad first job). If caught late enough, this results in a law suit. (Seen it happen from afar)
If you try to hide your bugs, paper over them, and somebody gets killed... that's where the crime comes in... Looking at you Boeing.
I thought it kind of odd the author asked randos off the street to define "engineering"
Back in '47, the ECPD, which later more or less turned into the ABET, used the definition:
"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property."
It would seem programming-type-stuff is more of a technical craft than an act of engineering. Ideally on the best days on projects of small scope, programming can approach engineering levels of rigor.
The tolerance for bugs is vastly higher in programming than in structural steel engineering, for example. There are no valid statistical analysis techniques for programming to reliably predict quality of code, although infinite conflicting opinions exist alongside some rather trivial rules. Some "full stack" types approach full cognizance of their design; but its rare outside narrow areas like embedded or device driver designers. Economics of operation is usually hand waved away with "moores law" and "batteries always get better over time", and environmental impacts (aside from mere greenwashing and virtue signaling) are ignored. Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard, programmers are like "here's a URL to the docs for the API from a couple versions ago best of luck to ya".
I'd say on the technical continuum that programming is very much like village blacksmithing. Somehow in general the horses get horseshoes but its not cheap, efficient, safe, clean, predictable, or fast.
The future being distributed very unevenly, I'd predict we'll see the first widespread "real engineering" of computer-stuff appear in corporate IT departments probably revolving around statistical analysis of cloud computing.
Mechanical engineering has specifications for "bug" tolerance.
These are manufacturing tolerances and safety factors.
Unless you're testing the piece of steel you're bout to use, you don't really know that it's yield strength is what the box says. Similarly, the welding might be done by an apprentice with a bad teacher, and during maintenance, the repair guy might run out of a certain bolt and use a different one with a washer.
Keep in mind that you do things to alleviate the possibility of "bugs"
When you purchase Steel it is purchased to a specification (such as minimum yield strength) if the steel fails to meet those specs the supplier can be held liable.
In software terms I suppose the equivalent would be purchasing a commercial library with support from vendor.
For major construction projects welds are inspected and singed off on, they may be tested as well.
Again in software terms equivalent would be code audit and test cases.
In construction there is a lot of inspecting stuff, signing off on it and certifying stuff. I think software people would go crazy if they had to deal with the same amount of paperwork.
> Mechanical engineering has specifications for "bug" tolerance.
That's what these days is referred to as an SLO.
Golden signals, USE, RED are ways of measuring them on a high level.
You program your systems to be resilient to a certain level of failure (retries, graceful failure), and you program them to be able to cope without a malfunctioning part by isolating it from the rest of the system (circuit breakers, bulkheads).
> Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard
Last year I took a job from a surprisingly big car manufacturer. They had designed and built a 2 million dollar glue dispensing machine. Only after it was fully assembled did they realize that they didn't have a way to get the glue into it. They needed it to be running the next week. Engineers run into bugs all the time, we just don't get convenient error messages.
This question gets more complicated in places like Ontario, Canada, where the term "engineer" is actually protected. To call yourself an engineer in a professional setting, you have to be a member of the Ontario Society of Professional Engineers. Of course in practice, they choose not to go after people who call themselves engineer vs developer, but perhaps that will change in the future.
Yes [1], my degree says Computer Engineering; so prima facia, that's what I am; I suspect some of my job titles said as much too, but job titles are easier to fake than degrees. I'm sure as anything not doing science. I bash on computer systems while they're running with whatever implements are near by; just like the people who run train engines do. Maybe that makes me a mechanic, but I feel like there's a distinction because there's a lot of original design in addition to fixing and modifying the work of others.
[1] Not in the State of Texas; I'm not licensed, and don't intend to be.
Mechanical engineer who worked as an energy engineer before getting his CS degree speaking here, but I'd tentatively say yes. I don't have a whole lot of experience using my CS degree yet but the main difference between a software developer/SWE/programmer and a hacker is the amount of paranoia that goes into making something. If you are a good software engineer, you've tested and verified everything and you've made sure there little to no risk to your end user. If you don't you're a hacker.
Not to look down on hackers, but the main reason I think this whole question exists in the computer side of the world but doesn't exist for mechanical engineers is that there isn't the hacker/engineer dichotomy in "traditional" engineering. Maybe makers vs mechanical engineers counts, but almost all of the makers I knew were employed as engineers.
A good software engineer/developer and a good "traditional" engineer take the time to think through every edge case, every corner case, and any other case that might cause problems. Makers/Hackers just get to the first thing that works, damn the consequences for anyone else. Which is fine because often the only people using their product is themselves.
I suggest you avoid using the word hacker, as to me you are using it in a negative sense, while missing that a good hack can be excellent engineering. “Hacker” contains a wild variety of behaviour and skills. The concept is too amorphous and people have wildly disagreeing meanings associated with the word (the meaning is very audience and context sensitive) so it is difficult to use the word as a proxy for the sense you wanted to convey, in a discussion with a wide audience.
Edit: I am suggesting hacker is a loaded/confusing word that is definitely not the opposite of engineer. Good engineering and good hacking are compatible - the right temporary fix can be excellent engineering. Cowboy (≈hacker) mechanical and civil engineers exist, so the concept of hacking is not incompatible with engineer. Using the word hacker intrinsically includes the concept of software, so contrasting hacking and engineering is not a tidy argument.
Think of it this way - a hacker will give you an MVP. An engineer will take an MVP and turn it into true-blue infrastructure or if that can't be done, give you a technical analysis detailing why not. In some (many) cases, a person will need to do both and they both require their own skill sets. I agree they aren't mutually exclusive, but I never wrote what I wrote to imply that.
Your sentence “there isn't the hacker/engineer dichotomy in ‘traditional’ engineering” can be paraphrased as: there is a dichotomy between a hacker and a software engineer... aaarrrgh!!
I am saying I have trouble following your comment, and your reply is confusing me further. I just wanted to say that using “hacker” as part of a comment will often cause confusion.
Disclaimer: I studied as an electronic engineer, and I consider myself a software engineer (I engineer my software carefully to work reliably as designed: although I can admire a good spaghetti cowboy solution if it meets some commercial or personal goal!)
Computational software engineer with physical engineering qualifications here -- we better be engineers on both sides of the divide! I suppose I don't really count though, as far as the question goes, since the software I write is used for doing physical engineering, and is a tiny fraction of software development, etc.
> "[...] that there isn't the hacker/engineer dichotomy in "traditional" engineering."
I'm sure there are as many "engineering hackers" out there as there are computer hackers, if not more. They just go by many names: DIYer, tinkerer, hobby mechanic, electronics enthusiast...
Yeah, there's definitely a wide spectrum. I just kind of lump them in as makers. Most of the people I've met at my local makerspace fit this bill - they're just tinkering with something or taking up a hobby. But as I mentioned, most of these people I've met are/were engineers professionally. I think it's just that on their personal projects they were more relaxed about "process" than they would be at work.
When I was in doing my Engineering degree in college, one of my professors once tried to make a spectrum of technical ability. One the low end he put "tinkerers" and on the high end he put "engineers." I think that's where a lot of my perceptions of technical ability are coming from. Like I said, it's just my opinion
In Canada the title "engineer" is a legally protected term. You can't legally call yourself a software engineer without going through the Engineers Canada accreditation.
I had a friend question me for calling myself a software engineer (even though they referred to themselves as one.) I've been programming for 15 years (8 years professionally) by 26 but they were unemployed and not practising after getting their BSc.
So in my opinion, there's more charlatanism coming out of academia than from honest professionals who have established a career and deep knowledge of their profession. But then again, I'm not building dams and bridges. So the answer mostly depends on what you're doing and how you got there.
Is there a source on this? I thought this was for specifically for "Professional Engineer" status. If not, myself (3 year college program grad) and many, many others are not what our current titles are as given by multiple employers.
I've asked many times even on these forums and have yet to get a credible source on this. I've been officially "called" sw engineer as per job title for roughly over a decade with 4 different large employers. I've never given this premise much credibility because of that, and perceive it to be wishful gatekeeping. I am hoping for some kind of clarification however.
I'd like to retire one day being able to say I've built a 40-50 year career while being a living, breathing lie. That makes me chuckle. =)
Gatekeeping is the entire point of professional bodies, and certifications. It is suppose to show that people with those qualifications have sufficient skill and experience to do the role.
This is one of the many problems with IT. I've interviewed many people with IT Security certifications who cannot explain the difference between encryption and hashing.
On the flip side, it is one of the great things about IT, that you don't need to go to university to get a job.
"An engineer is an individual who has been issued a licence to practise engineering by a provincial or territorial engineering regulatory body after demonstrating that they have the requisite education, skills, knowledge and experience. An engineer is sometimes referred to as a licensed engineer, a registered engineer or a professional engineer."
Professional engineer and engineer are both functionally equivalent and protected. You can't legally have the term engineer in your title in Canada unless you are an accredited engineer and pay your dues.
This source would need to serve as a proxy to the real source (if it exists) in law that claims these rules are in fact, actual law. That is what is being asked. This is not law, it rather a organization on a plight to attempt to make it law. Please correct me if I'm wrong.
I have never heard of a software engineer *requiring* a licence to do their work. How many titles out there have sales engineer? Have you ever heard of a Sales Engineering program to graduate from? I'm not one to flaunt laws, but it's hard to imagine a large portion of companies, some very reputable, are illegally employing boatloads of engineers in Canada. On a lighter note, it's also hard not to imagine that this organization is the personified Karen of engineering gatekeeping. Is there anything, anywhere that actually sources Canadian Law?
I have never in any software engineering position I've ever applied for seen any form of "Applicant must show an engineering licence to be considered". Why is that not ever seen? Shouldn't all these companies be abiding by the law?
I'm simply leaving all doors open to prove it wrong with an open mind, but the evidence has to be clear. Is it part of law or is it not? And if so, from an official source, where?
Also, digging deeper in for example the Ontario section of your source about licencing:
> Licence “Professional Engineer”, “Engineer” or “ingénieur” “P.Eng.”
This is exactly what I was referring to. They consider all of these monikers to to be in a "Professional Engineer" context. To interpret: not all engineers are professional engineers, but all professional engineers are engineers, and they will fight tooth and nail for the P.Eng protection. Hence my question about "Professional Engineer" status.
Not quite. All engineers are professional engineers. The term engineer is protected and you are not an engineer unless you also are a professional engineer. No P.Eng. then you're not allowed to advertise yourself as an engineer.
The vast majority of people without P.Eng do not advertise themselves as engineers as deception, as it's their employers which have given this title. If that is still against the law, I suppose I am witness to many thousands of companies breaking the law by employing many more thousands of people that they have labelled as engineer, yet without P.Eng.
LinkedIn would be a simple search on this. Can you say why there are no fines or action being taken? I work with hundreds who have been given the engineer title, yet many more of us do not have P.Eng designation than those that do. How on Earth have the thousands upon thousands of us not been contacted even once in our decade(s) of employment, over multiple companies? We are openly breaking the law, after all, correct?
I believe the employees personally would be exempt, correct? As they are have been given these titles by their employing body and not self proclaiming a different title given upon them.
>Can a person with an engineering degree call themselves an engineer in Canada?
>No. Individuals with an engineering degree are known as engineering graduates, and a licensed engineer must take responsibility for their engineering work.
This source would need to serve as a proxy to the real source (if it exists) in law that claims these rules are in fact, actual law. That is what is being asked. This is not law, it appears rather a organization on a plight to attempt to make it law. Please correct me if I'm wrong.
I have never heard of a software engineer requiring a licence to do their work. How many titles out there have sales engineer? I'm not one to flaunt laws, but it's hard to imagine a large portion of companies, some very reputable, are illegally employing boatloads of engineers in Canada. On a lighter note, it's also hard not to imagine that this organization is the personified Karen of engineering gatekeeping. Is there anything, anywhere that actually sources Canadian Law?
I have never in any software engineering position I've ever applied for seen any form of "Applicant must show an engineering licence to be considered". Why is that not ever seen? Shouldn't all these companies be abiding by the law?
I'm simply leaving all doors open to prove it wrong with an open mind, but the evidence has to be clear. Is it part of law or is it not? And if so, from an official source, where?
The jurisdiction of the regulation of Engineering in Canada is provincial. Accordingly each province has a law, such as the Professional Engineers Act in Ontario [1], which creates the regulatory association and gives it power to enforce its bylaws under the Act.
The Act is a bit different in each province. The Act for Ontario says
> Offence, use of term “professional engineer”, etc.
>(2) Every person who is not a holder of a licence or a temporary licence and who,
(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
...
>is guilty of an offence and on conviction is liable for the first offence to a fine of not more than $10,000 and for each subsequent offence to a fine of not more than $25,000. R.S.O. 1990, c. P.28, s. 40 (2); 2001, c. 9, Sched. B, s. 11 (59).
only if you are using the word engineer in such a way that would lead someone to believe that you are engaging in the practice of professional engineering is it illegal.
The practice of professional engineering also has a definition under the Act:
>“practice of professional engineering” means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising that requires the application of engineering principles and concerns the safeguarding of life, health, property, economic interests, the public welfare or the environment, or the managing of any such act; (“exercice de la profession d’ingénieur”)
If the activity being performed does not affect safeguarding of life, public welfare, or the environment you are probably off the hook and not leading anyone to believe that you are practicing professional engineering and can use the word engineer in your title and nobody will care.
If the activity being performed could kill someone or damage the environment and you are using the title of Engineer then that is contrary to the act and if something goes wrong and someone wants to file a complaint with the regulatory body against you for representing yourself as an Engineer when in fact you are not then you could be found guilty by the regulatory body's complaints committee.
So it depends what software one is writing does:
Crud app? probably not professional engineering
web site? probably not professional engineering
software that controls a dam spillway? probably professional engineering
software that controls traffic lights? probably probably professional engineering
software that controls a vehicle on a public road? probably professional engineering
software that controls an airplane? probably professional engineering
Thanks for asking the question and prompting me to dig in to this a bit more.
It is not limited to the title of “Professional Engineer”. If the software or activity could harm someone or the environment so the activity matches the definition of “professional engineering” defined in the Act and the programmer or person undertaking the activity is calling themselves anything with engineer in the title and are not a P. Eng then they could be fined under the Act.
In Canada One needs to be careful as to what projects they take on if they are calling themselves anything with engineer in the title.
> In Canada the title "engineer" is a legally protected term. You can't legally call yourself a software engineer without going through the Engineers Canada accreditation.
I have seen it argued that because HN is founded by Americans everything should be assumed to apply to America unless otherwise stated.
As HN readership isn’t strictly American, I don’t see why specifying that engineer is a legally protected title in Canada is a bad thing...
From the article, Mat’s previous job was Geological engineering. “His firm was hired to analyze a block cave in British Columbia.”
Also from the article “In Canada you can’t even call yourself a “Software Engineer” unless you’re accredited!”
The article specifically mentions Canada.
I’m sorry if I’m not reading into the most generous possible phrasing of your comment, but I can’t figure out what point you’re trying to make.
To me this is similar to the comments of the form “found the x” on HN. In this case you could have said “found the Canadian” and I still wouldn’t know what point is being made.
So, to my point, HN has international readership, some of which is Canadian, having people on HN point out some of the specifics about practicing engineering in Canada (or any other country for that matter) seems to be a useful addition to the commentary. Some HN readership is still in high school or early into their college or university studies and not everyone has access to the same resources, mentors, or even knowledge of where to research answers to their questions. Sharing on HN is a great thing and can be beneficial to these people. I know I’ve personally benefitted a great deal from HN comments.
The point I am making is that in any Hacker news thread about "engineers" somebody will always bring up this Canadian thing. To the extent I have now read this fact at least a dozen times.
We have discovered whether you can use the title engineer depends on if your activity concerns the safeguarding of life, public welfare, or the environment. If it does, you should stop calling yourself an engineer. If it does not, then you are not going to lead anyone that you are engaging in the practice of professional engineering and can more safely run the risk of calling yourself an engineer and being open to the regulatory body complaints committee.
Who cares? "Real" engineers love to gatekeep the term because they think there's an aura of prestige associated with the term, and they think that software developers calling themselves engineers are trying to steal valor. But in the present economic environment where fake engineers can make much more money than real engineers, why would anyone want to pretend to be a real engineer?
I tend to think of engineers as people who apply scientific and mathematical techniques to solve real world problems. Clearly some programmers do these things, but equally clearly some programmers do not! Why would you expect a yes or no answer?
Did you design some software or hardware? Did somebody pay you for it? Congratulations, you're an engineer. That, plus $4, will get you a cuppa joe at Starbucks.
I like the author's conclusion and I think a good litmus test for the difference between craftsmanship and engineering is the adage, "If you're not taking measurements, you're not doing engineering." So when we systematically measure and improve performance, security, productivity or what have you, we are doing engineering.
No, because when software "engineers" are told to build a bridge, two weeks before the bridge is set to open, the dependencies change because they found out no one was using the bridge, so now it's a train bridge. Also instead of going over a river, it's going over a highway, also it's 1/3rd the length. Just need to change some function calls right?
This is just silly. Lots of hubris here. It's also silly to spend much time thinking about this.
Of course we are engineers. OP uses "building a bridge" as an example of 'real' engineers. This is patently ridiculous on the face of it.
The one thing that unites us is we like to build. Whether it's the great pyramids or the latest social network, engineers are the ones who get it done.
We build. That's what engineers do. We build something to solve some problem whether it's with bits and electrons or with larger physical mediums like slabs of concrete. Engineers are builders and they build to solve some particular use case.
"Scientists build to learn. Engineers learn to build"
I believe the comparisons between how engineering is practiced make this more than "silly". The purpose of the writing is not to answer that shallow question, but to better understand both fields.
When OP said that we are not 'real' engineers because we have not built a bridge is when I stopped reading. For how could anyone take him seriously after that?
'Real' engineers are not judged by whether or not they can build a bridge as if it's some rite of passage to being a real engineer. That's ridiculous on the face of it.
That he used this example as some kind of proof to justify his argument is where he lost me.
This was in reference to a quote from a software developer comparing software development to building a bridge. That is why "he has never built a bridge" was emphasized.
Not sure if it applies to engineers, but there's a difference in the job description between defining and implementing. Sometimes someone knows some theory, does some math and is done. And his or her result is passed to another person that implements it. Sometimes it's the same person doing both, but probably less often. Sometimes the implementer grows and starts putting down some ground rules (becomes an architect) or the other way round (for example there because might be more jobs for implementers).
Perhaps another distinction is between trying something and see if it works, and knowing it will work (or won't work) before it's implemented. Then the difference is between knowing from experience and knowing from having studied the theory (and having worked through the proofs).
More specific questions can be readily answered - is software engineering as demanding of perfect execution as other engineering disciplines? are software engineering projects completed on time more/less relative to other disciplines? does software engineering require formal certification to practice? does it have a component of skill in that people who put in more time or have more aptitude do better than others? is it more critical or less critical to
But the "are we really engineers" question, like many others about definitions is destined to go in circles IMHO. Most important quote from the post:
> It’s a standard Wittgenstein game problem: human constructs do not neatly fall into precise definitions.
The actual debate seems to be around social status.. are software engineers as high up the social status ladder as "real" engineers? I don't know/care. Play stupid games, win stupid prizes :D If software engineering stays a sufficiently selective, high-paying, important field for long enough, it will gain the prestige to be considered "real" engineering. Otherwise it will not.
I think it will become both - more bifurcation. The top salaries & status will be reserved for 1/10th of the engineers. A lot of the bottom will become lower paid and more automated, closer to technical support.
142 comments
[ 2.9 ms ] story [ 258 ms ] threadI’m just as surprised to see the number be this high. I can’t help but wonder if this might be due to survivorship bias: crossovers are, after all, self-selecting. Perhaps not all engineers would say the same, if forced to swap roles.
Regardless, I’m excited to hear more from these crossovers. As a (soon-to-be) recent graduate, I think there can tend to be a great difference in perception between CS students and Engineering students, particularly at institutions without rigorous CS programs. Many tend to view CS students in the same way that some CS students view bootcamp students- people motivated by an “easy path to success”. I’ve found this opinion is rarely held of engineering students, given the reputation of engineering programs. I think it’s very useful to profile the motivators, mindsets, and general attitudes between the disciplines, if only to see that perhaps the difference isn’t as large as one might assume.
It was easy to learn programming. One reason was that the tools were always relatively cheap (even when they cost money), and the cost to learn by trial and error was negligible. At least this is true for the basics. Becoming a good programmer who can be an asset to a large project is outside my wheel house, though I'm in the process of learning.
Today, for mechanical design, you at least need access to SolidWorks, and the part of learning that comes from experiencing failure is costly and time consuming. Surely 3d printing is changing that equation, but not overnight.
But you can test the waters of programming without asking anybody for permission, and if you discover that you hate it, then you can just bury it. And many do. Programming is hard or most people, for reasons that I don't think we understand.
Now, programming and mechanical design by themselves are not engineering, but if someone wants to get into a new skill through the back door, they are similar. A person with SolidWorks skills can be useful as a designer without being a full blown engineer.
We certainly view our pure CS people as experts in what they do -- and the things I see them do are, e.g., build out cloud based versions of our product, add new GUI features, automate build and test systems (until management tries to replace them with us... a dubious proposition at best). That's just the stuff I see day to day, since it's most closely tied with us on the numerical side. Why wouldn't that be engineering? I could speculate but I don't care to. We are all working to make the product the customers want.
You can't call yourselves 'hackers' and 'engineers' at the same time. (I mean, you _can_, but talk is cheap)
That's not a bad thing by a long shot. There's a time and place for hacking as there is for engineering.
Software is different in a lot of ways. Especially at the high level, you are solving a puzzle. Let's say you need to generate a report. You've got all the tools in your language and several libraries. You know you'll have to talk to a database, pull down data into some kind of data structure, open a file handle, write the data, close the file, and save the results somewhere and then send an email. Is it technical? Yes. Challenging, well...maybe not this example, but software can be very challenging yes. But is it engineering? I wouldn't call it that. And no, I'm not sneering at it, or calling engineering superior. I just see the two as very different.
The stuff you do in engineering school (calculus, differential equations, statistics, linear algebra, circuit analysis, signal processing, Fourier transforms, control theory...etc as tools to solve problems with radio, industrial machines, turbines..etc) has pretty much zero to do with web design, standard business apps, databases, compilers...etc. If you use engineering as a general term to mean "make technical stuff" than you could apply it to either field equally, but engineering has already had a definition for many years and software is it's own thing. So use the term "coder", "developer", "programmer", "hacker", "complexity guru", or even "software engineer" as they all make sense. But the general term "engineer" would apply to mechanical, electrical, chemical, industrial, civil, biomedical...etc. All of those fields have the same core math classes and they then usually share an intermediate set of classes (thermodynamics, dynamics, statics, circuits...etc) before the advanced classes which specifically apply to your field. I don't think a very high percentage of coders (amazing, technical, often better paid, and very valuable as they are) have an overlapping lineage and language with what you would think of as traditional engineering. Believe me when I say I'm not gatekeeping the term either. I just honestly feel like there these things are taxonomically different. Maybe a new single word term should exist to convey what software developer does with two words.
The people who write software for a space-shuttle do engineering work, your average app store app is likely not 'engineered'.
I think it matters because it says a lot about how seriously the software industry as a whole takes the quality of its products and to what standards we hold software and with what goals in mind we make software. If we treated software like engineers treat aircrafts we'd likely have a lot less of it, but what we had would probably not crash that often.
The debate is tied to the debate about why so much software today feels so terrible and bloated and that makes it relatively important in my opinion.
It really isn't.
The definition of engineer is "a person who designs, builds, or maintains engines, machines, or public works."
We're building software engines, machines, and public works. Just because we're applying it for the software incarnation of the concept doesn't break the definition.
This is getting silly.
How isn't that like claiming you're a chef because you have a catering company where you serve microwaved foods, and claim it's silly to try to distinguish degrees of cooking skills.
In doing so, we see what lessons there are to take from each other, and gain a better understanding of both fields. For example, the author cites that version control is an innovation that traditional engineering could hugely benefit from.
By the definition you gave, no one can be a chemical, industrial, or electronic engineer. Silly!
Can decisions be motivated by clear objectives and rigorous deductive reasoning, which are useful to validate the design process and also to clearly communicate what is being done and why?
A lot of conventional software “knowledge” is too hand-wavy & wooly (not to mention fad-driven) to pass that threshold, imho. A lot of software platforms/infrastructure we use is the way it is for fairly arbitrary historical reasons, quite apart from the fact that many domains where software is applied are quite hard to parametrize rigorously. There are islands however, where the design is fairly rigorous and could be considered closer to the spirit of “engineering”. But the most important input for a craft to mature into engineering is time and rigorous effort.
Either ways, I don’t see this question mattering too much in immediate practice.
Engineers should be able to understand design principles and be able to architect a new system from those principles. In today's world i think we are moving further away from this than closer. We spend much of our time learning trivia such as how to fiddle with a particular software platform to get it to work.
Additionally with all the various abstractions that we have built (lock-in cloud services, high level languages, proprietary platforms, etc) many people are no longer capable of discussing with you what is happening on the CPU or how data should flow through a system or the disadvantages of a distributed architecture, etc.
I think that software engineering is still in it's infancy in someways and hasn't yet matured enough to be an engineering discipline. That being said there is an egalitarian quality about being a "software engineer". We're all software engineers.
Engineering is very much about the accumulation of experience - the reason all the planning is up front isn't because the Secret Society of Engineers said so, but because they are practicing something that has between hundreds (electrical, maybe ~200 years) and thousands (mining, dates back to the stone age) of years experience.
In 100 years, software engineers will have an enormous advantage over almost all non-engineers at designing and running software projects. There'll be a few amateur prodigies that nobody trusts, and putting an engineer in charge of software projects will mysteriously trigger a lack of things going wrong.
Software isn't unpredictable. Nearly nothing is unpredictable. The process of figuring out which bits are predictable isn't finished because the hardware keeps changing and forcing the tech stack to change. When the S-curve of hardware progress flattens, software engineering will gain in importance.
* Changed from 20-30 because that was wrong. Changes none of the arguments.
> the discipline is all of 20-30 years old.
Is kind of silly. The term "software engineering" originated in the 1960s, well beyond your range for it.
The strongest indication programming is not engineering is forgetting and reinventing the past. Also revolutionary tools and techniques are invented far too often in CS.
In mechanical engineering we've had screws for a few centuries and off the top of my head the most recent innovation in screw fastener tech was the creation of the "Torx" screw standard in the 60s. The Torx innovation was due to smarter torque controlled automatic screwdrivers on assembly lines WRT electronic drive tech and early digital control.
Gas, Diesel, Turbine, Rotary, in-line, V, Turbo, Carburated, SuperCharged, SkyActive-X etc.. etc..
While the basics principles are the same and over 120 years old, the Combustion engine has been re-invented and re-engineered a gazillion of times...
Maybe some of you guys here are young, but there were cars (large SUVs, or Sports Cars), that would consume 8-9mpg, yet still be slow as molasses compared to today's cars.
So, yes while the basic principles of the combustion engine are the same... but it has been re-engineered (from scratch), a many times, and each time it would be slightly better and better.
Same with planes, jets, tanks, etc...
Then there are innovations in manufacturing enabling new designs. 3D printing is coming along. Not everybody has to pull from a catalog of shapes, thicknesses, etc, for structural design.
If it was engineering, or even a “profession”, experience would be prized, instead ageism is rampant.
20-30 years? You think software engineering began in 1990 at the earliest?
Common production software, GCC for example, is older than that.
God knows 10 years ago is always gonna feel like 1990.
You are right that software engineering is a relatively young field, but people have tried to apply engineering principles to software since at least the Fifties. The term itself was coined sometime in the early 60s and was used by the ACM in 1966.
How do you define software engineering such that it's 20-30 years old? Why isn't it 50 years old? I ask because I've heard the argument that software engineering is a young discipline but it feels like you're really stretching it with those 20-30 years.
>When the S-curve of hardware progress flattens, software engineering will gain in importance.
But a lot of software engineering issues are entirely divorced from the underlying hardware. So I'm not sure how the shape of hardware has any significant bearing to our current situation.
>Engineering is very much about the accumulation of experience
I would argue that we actually know a ton about how to build software. It's just that it's not really being taught or valued or applied. I would argue that's an important distinction because it strengthens the analogy of electrical engineer vs electrician. So it's more about just an accumulation of experience.
To play devil's advocate with the other's position, even just over the time I've been in software since the early/mid 2000s I've seen things shift a number of times as new hardware creates new demands from our software or obsoletes old development struggles. PC RAM capacities rising 100x from 20+ years ago, more operations coming over on a slow and flaky WAN from untrusted devices, fewer people tolerating apps that only work on the tower PC stuck on their desk, more apps expected to sync state across devices because they're cheap enough we can own a bunch of them, use cases we learned to handle with plugged-in tower PCs adapting to power-draw-sensitive mobile devices, mobile devices being 1.5GHz instead of 16HMz, CPUs becoming fast enough that performance is often a footnote concern for whether to implement crypto, dedicated AI microchips changing what's possible on-device...
All of these seem like very reasonable justifications to rethink the way we build software, to change what's standard practice or to invent new tools that solve old problems in a modern context. To some degree the clock on when our industry starts accumulating stable knowledge won't start ticking until these kinds of changes stop happening.
But we already have stable knowledge that's simply not considered valuable. Your list of changes over the decades is of course a change but I don't understand why the attitude is "unless things stay stable over the next 30 years, there's no point in trying".
All those SOLID, agile, TDD, DDD, micro-services memes that are being implemented so superficially and cargo-cultishly are actually grounded in a real understanding that has a context, constraints, and trade-offs. The issue is that superficial and cargo-cult application. "Software engineers" that decide they're going to do micro-services without understanding what it solves, how it solves it and what they're trading off. And a business that doesn't care or know enough to ask for better. Maybe they don't need better! Maybe it's ok to slap together and the product will be equally mediocre whether the devs use cargo-cult pattern X or not. Maybe the quality doesn't matter that much to the business. In which case the devs being hired also don't need to actually know that much software engineering. In which case maybe the idea of electrical engineer vs electrician makes sense here too.
That said; which engineering field are you basing this on? I thought that generally only lead engineers or architects were responsible in that way.
If you try to hide your bugs, paper over them, and somebody gets killed... that's where the crime comes in... Looking at you Boeing.
Back in '47, the ECPD, which later more or less turned into the ABET, used the definition:
"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property."
It would seem programming-type-stuff is more of a technical craft than an act of engineering. Ideally on the best days on projects of small scope, programming can approach engineering levels of rigor.
The tolerance for bugs is vastly higher in programming than in structural steel engineering, for example. There are no valid statistical analysis techniques for programming to reliably predict quality of code, although infinite conflicting opinions exist alongside some rather trivial rules. Some "full stack" types approach full cognizance of their design; but its rare outside narrow areas like embedded or device driver designers. Economics of operation is usually hand waved away with "moores law" and "batteries always get better over time", and environmental impacts (aside from mere greenwashing and virtue signaling) are ignored. Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard, programmers are like "here's a URL to the docs for the API from a couple versions ago best of luck to ya".
I'd say on the technical continuum that programming is very much like village blacksmithing. Somehow in general the horses get horseshoes but its not cheap, efficient, safe, clean, predictable, or fast.
The future being distributed very unevenly, I'd predict we'll see the first widespread "real engineering" of computer-stuff appear in corporate IT departments probably revolving around statistical analysis of cloud computing.
These are manufacturing tolerances and safety factors.
Unless you're testing the piece of steel you're bout to use, you don't really know that it's yield strength is what the box says. Similarly, the welding might be done by an apprentice with a bad teacher, and during maintenance, the repair guy might run out of a certain bolt and use a different one with a washer.
When you purchase Steel it is purchased to a specification (such as minimum yield strength) if the steel fails to meet those specs the supplier can be held liable.
In software terms I suppose the equivalent would be purchasing a commercial library with support from vendor.
For major construction projects welds are inspected and singed off on, they may be tested as well.
Again in software terms equivalent would be code audit and test cases.
In construction there is a lot of inspecting stuff, signing off on it and certifying stuff. I think software people would go crazy if they had to deal with the same amount of paperwork.
That's what these days is referred to as an SLO.
Golden signals, USE, RED are ways of measuring them on a high level.
You program your systems to be resilient to a certain level of failure (retries, graceful failure), and you program them to be able to cope without a malfunctioning part by isolating it from the rest of the system (circuit breakers, bulkheads).
Last year I took a job from a surprisingly big car manufacturer. They had designed and built a 2 million dollar glue dispensing machine. Only after it was fully assembled did they realize that they didn't have a way to get the glue into it. They needed it to be running the next week. Engineers run into bugs all the time, we just don't get convenient error messages.
[1] Not in the State of Texas; I'm not licensed, and don't intend to be.
Not to look down on hackers, but the main reason I think this whole question exists in the computer side of the world but doesn't exist for mechanical engineers is that there isn't the hacker/engineer dichotomy in "traditional" engineering. Maybe makers vs mechanical engineers counts, but almost all of the makers I knew were employed as engineers.
A good software engineer/developer and a good "traditional" engineer take the time to think through every edge case, every corner case, and any other case that might cause problems. Makers/Hackers just get to the first thing that works, damn the consequences for anyone else. Which is fine because often the only people using their product is themselves.
Just my $0.02
Edit: I am suggesting hacker is a loaded/confusing word that is definitely not the opposite of engineer. Good engineering and good hacking are compatible - the right temporary fix can be excellent engineering. Cowboy (≈hacker) mechanical and civil engineers exist, so the concept of hacking is not incompatible with engineer. Using the word hacker intrinsically includes the concept of software, so contrasting hacking and engineering is not a tidy argument.
"I'm just going to hack something together." (usually means do substandard work but with the benefit of speed)
"It works, but it's a nasty hack." (a workaround that might be clever, but isn't necessarily safe, testable, or repeatable).
A "hacker" in the sense that GP is using it means somebody who's default method of working involves doing the above on a regular basis.
Think of it this way - a hacker will give you an MVP. An engineer will take an MVP and turn it into true-blue infrastructure or if that can't be done, give you a technical analysis detailing why not. In some (many) cases, a person will need to do both and they both require their own skill sets. I agree they aren't mutually exclusive, but I never wrote what I wrote to imply that.
See also (caveat: I don't wholly agree with this): http://www.paulgraham.com/gba.html
Your sentence “there isn't the hacker/engineer dichotomy in ‘traditional’ engineering” can be paraphrased as: there is a dichotomy between a hacker and a software engineer... aaarrrgh!!
I am saying I have trouble following your comment, and your reply is confusing me further. I just wanted to say that using “hacker” as part of a comment will often cause confusion.
Disclaimer: I studied as an electronic engineer, and I consider myself a software engineer (I engineer my software carefully to work reliably as designed: although I can admire a good spaghetti cowboy solution if it meets some commercial or personal goal!)
Edit: “I don't wholly agree with this: http://www.paulgraham.com/gba.html ,” really displays that the meaning of hacker is a variable.
And yes, good engineering should always be admired and sought after. But hacking and making has its uses and charms.
I'm sure there are as many "engineering hackers" out there as there are computer hackers, if not more. They just go by many names: DIYer, tinkerer, hobby mechanic, electronics enthusiast...
When I was in doing my Engineering degree in college, one of my professors once tried to make a spectrum of technical ability. One the low end he put "tinkerers" and on the high end he put "engineers." I think that's where a lot of my perceptions of technical ability are coming from. Like I said, it's just my opinion
I had a friend question me for calling myself a software engineer (even though they referred to themselves as one.) I've been programming for 15 years (8 years professionally) by 26 but they were unemployed and not practising after getting their BSc.
So in my opinion, there's more charlatanism coming out of academia than from honest professionals who have established a career and deep knowledge of their profession. But then again, I'm not building dams and bridges. So the answer mostly depends on what you're doing and how you got there.
I've asked many times even on these forums and have yet to get a credible source on this. I've been officially "called" sw engineer as per job title for roughly over a decade with 4 different large employers. I've never given this premise much credibility because of that, and perceive it to be wishful gatekeeping. I am hoping for some kind of clarification however.
I'd like to retire one day being able to say I've built a 40-50 year career while being a living, breathing lie. That makes me chuckle. =)
This is one of the many problems with IT. I've interviewed many people with IT Security certifications who cannot explain the difference between encryption and hashing.
On the flip side, it is one of the great things about IT, that you don't need to go to university to get a job.
"An engineer is an individual who has been issued a licence to practise engineering by a provincial or territorial engineering regulatory body after demonstrating that they have the requisite education, skills, knowledge and experience. An engineer is sometimes referred to as a licensed engineer, a registered engineer or a professional engineer."
Professional engineer and engineer are both functionally equivalent and protected. You can't legally have the term engineer in your title in Canada unless you are an accredited engineer and pay your dues.
I have never heard of a software engineer *requiring* a licence to do their work. How many titles out there have sales engineer? Have you ever heard of a Sales Engineering program to graduate from? I'm not one to flaunt laws, but it's hard to imagine a large portion of companies, some very reputable, are illegally employing boatloads of engineers in Canada. On a lighter note, it's also hard not to imagine that this organization is the personified Karen of engineering gatekeeping. Is there anything, anywhere that actually sources Canadian Law?
I have never in any software engineering position I've ever applied for seen any form of "Applicant must show an engineering licence to be considered". Why is that not ever seen? Shouldn't all these companies be abiding by the law?
I'm simply leaving all doors open to prove it wrong with an open mind, but the evidence has to be clear. Is it part of law or is it not? And if so, from an official source, where?
> Licence “Professional Engineer”, “Engineer” or “ingénieur” “P.Eng.”
This is exactly what I was referring to. They consider all of these monikers to to be in a "Professional Engineer" context. To interpret: not all engineers are professional engineers, but all professional engineers are engineers, and they will fight tooth and nail for the P.Eng protection. Hence my question about "Professional Engineer" status.
LinkedIn would be a simple search on this. Can you say why there are no fines or action being taken? I work with hundreds who have been given the engineer title, yet many more of us do not have P.Eng designation than those that do. How on Earth have the thousands upon thousands of us not been contacted even once in our decade(s) of employment, over multiple companies? We are openly breaking the law, after all, correct?
I believe the employees personally would be exempt, correct? As they are have been given these titles by their employing body and not self proclaiming a different title given upon them.
>No. Individuals with an engineering degree are known as engineering graduates, and a licensed engineer must take responsibility for their engineering work.
https://engineerscanada.ca/frequently-asked-questions
I have never heard of a software engineer requiring a licence to do their work. How many titles out there have sales engineer? I'm not one to flaunt laws, but it's hard to imagine a large portion of companies, some very reputable, are illegally employing boatloads of engineers in Canada. On a lighter note, it's also hard not to imagine that this organization is the personified Karen of engineering gatekeeping. Is there anything, anywhere that actually sources Canadian Law?
I have never in any software engineering position I've ever applied for seen any form of "Applicant must show an engineering licence to be considered". Why is that not ever seen? Shouldn't all these companies be abiding by the law?
I'm simply leaving all doors open to prove it wrong with an open mind, but the evidence has to be clear. Is it part of law or is it not? And if so, from an official source, where?
The Act is a bit different in each province. The Act for Ontario says
> Offence, use of term “professional engineer”, etc.
>(2) Every person who is not a holder of a licence or a temporary licence and who, (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
...
>is guilty of an offence and on conviction is liable for the first offence to a fine of not more than $10,000 and for each subsequent offence to a fine of not more than $25,000. R.S.O. 1990, c. P.28, s. 40 (2); 2001, c. 9, Sched. B, s. 11 (59).
only if you are using the word engineer in such a way that would lead someone to believe that you are engaging in the practice of professional engineering is it illegal.
The practice of professional engineering also has a definition under the Act:
>“practice of professional engineering” means any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising that requires the application of engineering principles and concerns the safeguarding of life, health, property, economic interests, the public welfare or the environment, or the managing of any such act; (“exercice de la profession d’ingénieur”)
If the activity being performed does not affect safeguarding of life, public welfare, or the environment you are probably off the hook and not leading anyone to believe that you are practicing professional engineering and can use the word engineer in your title and nobody will care.
If the activity being performed could kill someone or damage the environment and you are using the title of Engineer then that is contrary to the act and if something goes wrong and someone wants to file a complaint with the regulatory body against you for representing yourself as an Engineer when in fact you are not then you could be found guilty by the regulatory body's complaints committee.
So it depends what software one is writing does:
Crud app? probably not professional engineering
web site? probably not professional engineering
software that controls a dam spillway? probably professional engineering
software that controls traffic lights? probably probably professional engineering
software that controls a vehicle on a public road? probably professional engineering
software that controls an airplane? probably professional engineering
Thanks for asking the question and prompting me to dig in to this a bit more.
[1]: https://www.ontario.ca/laws/statute/90p28
I think this fairly answers my original comment:
> I thought this was for specifically for "Professional Engineer" status.
In Canada One needs to be careful as to what projects they take on if they are calling themselves anything with engineer in the title.
Same in Texas. [0]
[0] https://pels.texas.gov/downloads/eb17.htm (search for "Software Engineering")
So in lot of companies the official title is software engineer even without any accreditation.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
As HN readership isn’t strictly American, I don’t see why specifying that engineer is a legally protected title in Canada is a bad thing...
From the article, Mat’s previous job was Geological engineering. “His firm was hired to analyze a block cave in British Columbia.”
Also from the article “In Canada you can’t even call yourself a “Software Engineer” unless you’re accredited!”
The article specifically mentions Canada.
I’m sorry if I’m not reading into the most generous possible phrasing of your comment, but I can’t figure out what point you’re trying to make.
To me this is similar to the comments of the form “found the x” on HN. In this case you could have said “found the Canadian” and I still wouldn’t know what point is being made.
So, to my point, HN has international readership, some of which is Canadian, having people on HN point out some of the specifics about practicing engineering in Canada (or any other country for that matter) seems to be a useful addition to the commentary. Some HN readership is still in high school or early into their college or university studies and not everyone has access to the same resources, mentors, or even knowledge of where to research answers to their questions. Sharing on HN is a great thing and can be beneficial to these people. I know I’ve personally benefitted a great deal from HN comments.
I provided a link as proof.
Of course we are engineers. OP uses "building a bridge" as an example of 'real' engineers. This is patently ridiculous on the face of it.
The one thing that unites us is we like to build. Whether it's the great pyramids or the latest social network, engineers are the ones who get it done.
We build. That's what engineers do. We build something to solve some problem whether it's with bits and electrons or with larger physical mediums like slabs of concrete. Engineers are builders and they build to solve some particular use case.
"Scientists build to learn. Engineers learn to build"
'Real' engineers are not judged by whether or not they can build a bridge as if it's some rite of passage to being a real engineer. That's ridiculous on the face of it.
That he used this example as some kind of proof to justify his argument is where he lost me.
Seems like you're just interested in name calling. When people resort to name calling it usually means they've lost the argument.
But I'm sorry you're having a bad day.
I'll leave it that. Thank you and take care.
Perhaps another distinction is between trying something and see if it works, and knowing it will work (or won't work) before it's implemented. Then the difference is between knowing from experience and knowing from having studied the theory (and having worked through the proofs).
But the "are we really engineers" question, like many others about definitions is destined to go in circles IMHO. Most important quote from the post:
> It’s a standard Wittgenstein game problem: human constructs do not neatly fall into precise definitions.
The actual debate seems to be around social status.. are software engineers as high up the social status ladder as "real" engineers? I don't know/care. Play stupid games, win stupid prizes :D If software engineering stays a sufficiently selective, high-paying, important field for long enough, it will gain the prestige to be considered "real" engineering. Otherwise it will not.
I think it will become both - more bifurcation. The top salaries & status will be reserved for 1/10th of the engineers. A lot of the bottom will become lower paid and more automated, closer to technical support.