Programmers should not call themselves engineers (2015)
theatlantic.com
theatlantic.com
But to me, engineers are people who build important stuff, that a lot of people rely on, and for which there will be severe consequences if it is built wrong. A lot of software falls into that category. Words evolve, I don't feel like I'm putting on airs describing what I'm doing as engineering (sometimes!), and hence I don't feel like some kind of pretender describing myself as a software engineer.
Also, there's a quote I love, although I can't name the source: "engineering is about tradeoffs". Well so is software development, all day every day - in fact it's the mark of real experience knowing where, when and why to make those tradeoffs. Sounds like engineering to me.
Dont care anout certification, but when you can "engineer" a solution that takes account those three factors you can call yourself a professional engineer.
Certain engineering standards require managed competencies, eg functional safety and equipment for explosive atmospheres, certification is probably the easiest path.
Most people who say, "meh but we are engineers because we make stuff" really don't have the first clue how engineers do engineering.
McKinsey’s found that 98%+ of construction projects run ahead of timeline, and 80% run over budget.
Software engineers also have those requirements, but we try to keep our estimates to small chunks instead of 5+ years.
You're a P.Eng when you can pass your country's certification. That's it, it's just a title.
But I have all the same training in both scenarios. Why would I be "better" at engineering if I'm looking at fiber cables or an AC generator but not python? I learned the same techniques, the same safety practices, the same thinking models.
In most parts of the software world I don't think there exists similar circumstances. I'm not sure if there are agreed industry best practices or certification requirements for most types of software development.
The real meaning for engineer is someone who builds complex stuff that require years of learning and practice for the majority of the population.
Having a set of defined rules to follow is not engineering, is safety based on previous experience, most car drivers also do that and they are not engineers.
Maybe we should acknowledge that it’s not as simple to define and that’s why articles like the one posted are writen.
It is a part of being an engineer, but it is not the entirety of the profession (I'd probably use the word Standards rather than rules). I think the software world has standards to for things like networking etc - does it count as a programmer following a set of rules if he writes networked software? Maybe...
>The real meaning for engineer is someone who builds complex stuff that require years of learning and practice for the majority of the population.
I don't think this really fits either. Throughout my career I have spent very little time building anything, a large amount of the work is optimizing existing problems/products/processes (this is where tradeoffs the GP mentioned comes in) "How can this be made cheaper, How can it become more efficient, How can it be made lighter etc."
If I had to come up with my own definition it would be something like "Engineering is solving technical problems within an applied set of Constraints" - That probably does not apply to a surgeon - but could be applied to software.
If only this were true for software...
If a car has a poorly-engineered suspension and a wheel breaks off and someone gets killed, does the engineer at Ford who designed it get sued personally? Absolutely not. Did any engineers at Ford who designed the Pinto suffer personally for their design? Of course not.
I believe the laws differ by country. In the above circumstance where I am based (Australia) the person who signed off (edit: certified) after reviewing the suspension design would assume the liability. And may get taken to court where you would need to demonstrate you followed best practices may be ask to supply calculations etc.
For example my company we are required legally to keep things like calculations and technical drawings on file in archives for things like above hypothetical.
edit: Article here: https://eea.org.au/insights-articles/make-defensible-safety-...
Surprising that no one in this thread has mentioned education as an additional distinguishing chracteristic. Programmers are frequently self-taught. If PG essays and HN submissions/comments are any indication, many programmers dislike school. It is said that programming only requires very basic math skills. There are requirements on professional engineers that do not apply to programmers. Engineering, in the US at least, is generally a regulated profession. That's the point of difference, irrespective of whether programmers perform similar work.
NB. When I use the term "regulated" I mean there are licensure requirements. For example, an exam.
https://www.nspe.org/resources/licensure/how-get-licensed
https://ncees.org/exams/fe-exam/
https://www.nspe.org/resources/pe-magazine/may-2011/industri...
No, it's not. Civil engineering is; the rest of them, not so much. The vast majority of engineers in the US fall under the "industrial exemption", whether they work for Microsoft, Google, Ford, GM, Boeing, or General Dynamics, or countless other companies large and small. Almost none of them have a Professional Engineer license.
It's weird how, every time this kind of discussion comes up, civil engineers keep trying to tell all the people who design fighter jets and cars that they're not "real engineers" because they don't have a license.
This is unlike programming, where "self-taught" or "dropped out of college" is sufficient.
To be fair I don't think we even have the tools to create software that we can be liable for yet, not without halting progress to a point where, without strong laws, companies cutting corners would win by iterating way faster.
Mostly the harm a software engineer can do will be in monetary losses and not in the loss of life. Also there is the fact, that a lot of the software written will be the process of communication, sparring, feedback and iteration so establishing that a single person is at fault would be hard to prove anyways.
However there are software devs that do have to tread with care (eg. in the automotive sector, defense or medical). The differentiator IMO is who is driving the demand for covering possible liability issues: The private sector or the government.
That by itself (or the cultural differences) shouldn't define what "Engineering" actually means, or should it?
Software engineering as a profession is so immature that we haven't seen many serious incidents yet. But people have died because of bugs. And this will only increase over time as we keep using more and more software.
What the vast majority of us in software do is not engineering. I think like you say liability is one part, but another big part is the immense breadth of unknowns we have to deal with and accept. There's no budget or time given for properly figuring out and scoping a project (for most programming), because the penalty for failure isn't so steep. It's not written in blood, so we don't dedicate the resources necessary to really engineer it.
Some programming is arguably engineering. Many parts of aerospace for example. Some of the medical devices space. But it's overall a very small percentage of total programming happening in that world.
And you know, that's probably okay, for now at least.
What the vast majority of us in software do is not engineering. I think like you say liability is one part, but another big part is the immense breadth of unknowns we have to deal with and accept, but never really chase down. There's no budget or time given for properly figuring out and scoping a project (for most programming), because the penalty for failure isn't so steep. It's not written in blood, so we don't dedicate the resources necessary to really engineer it.
Some programming is arguably engineering. Many parts of aerospace for example. Some of the medical devices space. But it's overall a very small percentage of total programming happening in that world.
And you know, that's probably okay, for now at least.
Also any kind of automation that might kill a human: industry automation, self-driving cars, etc.
A software engineer builds/architects complex systems in an efficient manner that utilizes a set of standards to do so. Software engineers actually use data structures, complex algorithms and engineering paradigms in their solutions.
A programmer does rote/formulaic (sometimes simplistic) work. Installs and customizes Wordpress sites with basic PHP monkeypatching. Cobbles together UIs with UI libraries and prebaked components. Builds COBOL and FORTRAN applications. Etc.
It's an arbitrary distinction and slightly biased; but one that I think fits. Both are needed and have places in the careerscape, but their utility is different. Much like a civil engineer and a safety inspector are both necessary, despite only one utilizing "engineering principals".
Sure, if you're working on medical devices or software controllers for devices in vehicles or nuclear reactors or whatever, but, as a fraction of the software industry, that's tiny. I don't have hard numbers on this, but you can look at popularity of programming languages as a proxy. Most software "engineers" do JavaScript or Python, two languages you would never ever use for such things.
Most software is a form of entertainment with a small amount of usefulness sprinkled in, or doing things that could, in principle, be done with paperwork.
Since it's a controversial word and opinions vary, why not just say "developer" or "programmer" instead?
A handyman is also an engineer by your definition, but insisting on that title would probably raise eyebrows too.
It is all the same stuff. Someone has an idea, then you figure out how to make that a reality, along the way figuring out who does what, figuring out how long it's going to take, adjusting your plans when new information shows up, reacting to setbacks, etc. Whether you're moving concrete or bytes in RAM, the essence of what makes engineering engineering is the same.
(Look at that building in San Francisco that is now tipping over. That's software engineering level of civil engineering! But it's all the same shit at the end of the day. A software engineer is surprised when Postgres doesn't hold up to their super cool new query that a million people want to run at once. A civil engineer is surprised when the geotechnical reports were wrong, they built their foundation the wrong way, and then their building starts tipping over. The common thread is that shit breaks and then we fix it.)
I think people are salty because the stakes in software engineering are relatively low, but the potential to make money is nearly unbounded. Nobody is going to die if your ad targeting software has a bug, but you can make yourself billions of dollars if you get it right. Civil engineers are not so lucky. If your bridge collapses because you messed up the math, that's something you have to live with. And people will only pay so much money for bridges. So that's definitely "unfair", but them's the breaks. At least you can point at what you made and say "I made that". When it doesn't collapse, people are going to be a lot more impressed than the software engineer with really good ad targeting.
I think people hear engineering and jump immediately to a handful of big professions like aerospace, or civil engineering, and build their view of engineering entirely based on that: very controlled, very life-or-death, everything needs to be done correctly, etc. But that's kind of like assuming that what Google is doing is representative of all software engineering. And while it's true that software engineering is probably one of the less mature branches of engineering, there are things that we do a lot better than other disciplines, like change management (i.e. git), or automated testing.
[1] https://www.bls.gov/oes/current/oes151251.htm [2] https://www.bls.gov/oes/current/oes151252.htm
The secret to making a lot of money on a bridge is not to sell it. Follow the software world’s example and make it a toll bridge. Collect a hefty rent on all the traffic coming in and out of a major city. Make a fortune!
Chartered institutes don't prevent damages nor help much with liability. Watch real disasters happen and work out whether (a) the registration of engineers prevented the risk or (b) whether engineers were the root cause.
Use laws to hold people accountable for the safety of others - regardless of their academic tickets. It isn't as though engineers are the only discipline that can fail!
In a modern world engineering and liability can easily cross international borders. Chartered institutions don't help much except within the borders of a country for home projects.
It's true the generic field of software engineering has some bogus stuff, but the actual quality of "you have standing against a professional board assessment" is actually there, and valuable (in my opinion)
"You shouldn't call yourself a software engineer if you aren't chartered" might be a better take on it.
My degree (1982) in computer science missed out on charter status by a year. I could have up-lifted but I was lazy. I do regret this sometimes. I would love to have been an engineer, purely as a personal achievement. I kept membership of the BCS until pretty much this year. Engineers in the BCS get a distinct grade of membership, with all the CPD and indemnity stuff, I was just a member.
Humerous aside: There is a worshipful company of computer professionals in the UK, with official livery, and an order of precedence in the Lord Mayor's dinner, against the cutlers, the butchers, the goldsmiths. They do good works, Charity, and advance the cause of computer science. This is distinct from the British Computer Society.
When I moved over to the software world, I didn't really notice an appreciable difference from the work I was doing when I had "engineer" in my title. You're still solving complex problems, accommodating for edge cases, and translating requirements into deliverables. The only differentiator is that I went from producing something physical to something digital. So I call myself a "software engineer" without really thinking about it. Nobody ever blinked an eye when I said I was a mechanical engineer. Nobody dug into whether I was accredited or licensed. One could argue that distinguishing between a programmer and a software engineer is analogous to a drafter vs a mechanical engineer, but that seems wrong too. At the end of the day, you can call me whatever you want as long as the check clears.
A Roman-era civil engineer transported to _now_, a good 2000 years into the future, would still find gravity working exactly the same, concrete working the same, and will not find any of our modern architecture truly alien or incomprehensible.
Computers? Take a programmer form merely 50 years ago and: CPU executes instructions one by one? Nope. You program starting from hardware? Nope. A JavaScript framework collection? Completely alien.
Imagine best practices for bridge building if gravity was variable and susceptible to fashion cycles.
What if creating software is closer to investigative journalism than to building bridges? Consider this, a small subset of professions falls under the umbrella of engineering. There are chemical engineers, mechanical engineers, electrical engineers etc. There are no sports engineers, law engineers, or literature engineers. Some people activities are just not engineerable. This doesn't make them any less important, so I deeply disagree with "programming cheapens engineering" statement.
And it's not that software is a novel concept. In fact, the very argument that software is new and is not yet properly regulated is becoming old. Software is older than spaceflight, computer tomography, and mobile telecommunications, - all heavily if not excessively regulated.
Somehow, creating software dodges most of the attempts to make it into an engineering discipline. Somehow, most of the norms and rules we invent don't pass the test of time. There is the SWEBoK, there are also ISO standards for computer languages, and their use, but the art of programming still remains orthogonal to the standardization effort. Most of the software outside safety-critical systems is still created by artisans and not engineers. And... it's ok. Maybe you don't need a license to write a yet another dating app.
So maybe software engineering is indeed a misnomer. Like a racoon dog, a guinea pig, or MTV.
The author probably don't know that the Chinese government actually demands similar terms too: you are not allow to sell a piece of software unless the software passes a few certifications, and you must hire enough employees graduated for few government recognized majors/professions in order to start a tech company that's allowed to request those certifications. So I guess China could be a dream country for the author of the article. Welcome BTW.
Of course, the entire article was written by someone who has a half-knowledge on what's actually going on, resulted in a flamewere. The mentioning of data breaches can't cover the fact that most software (or digital control systems in general) worked very well, you don't hear from it because there are no people complaining.
It can be very problematic if one judges things only based on headlines, because the resulted reasoning might collapse as soon as someone else applies the same logic elsewhere. Say, why a well-engineered dam, built by fully certified engineers with their state-of-the-art disciplinary knowledge, meticulous calculation plus simulation and rigorous construction still failed and caused many lives? Are dam engineers not engineers?
The dam engineers would probably come out with some excuses such as real-world complexity, and they would be damn right. Handling a dynamic system is hard, and software engineering is full of it.
This gives me the title “Diplom-Ingenieur” (diploma engineer) which according to Austrian law essentially becomes part of my name. I can (but don’t have to) add my title to my passport, drivers license etc. It’s also added in legal documents.
To say I’m not allowed to call myself an engineer because my field is not rigorous enough just feels like a weird form of gate keeping.
Electrical Engineering and Computer Engineering definitely meet this criterion but Software Engineers rarely have to deal with anything but pure abstraction. It's like calling a Mathematician an Engineer IMO. At the same time the term is SWE so I'll go with it.
It's only really a problem when you have, for lack of a better term, codemonkeys calling themselves engineers, because they are not engineering anything.
To exclude software from the field of engineering is baseless gatekeeping.
I don’t care either way. I just call myself a programmer.
Meanings of "engineer" according to Merriam-Webster:
1. a member of a military group devoted to engineering work
2. crafty schemer
3. a designer or builder of engines
4. a person who is trained in or follows as a profession a branch of engineering
5. a person who carries through an enterprise by skillful or artful contrivance
6. a person who runs or supervises an engine or an apparatus
I guess at some point some folks were also grumpy that the word was generalized to people who had no relation to military :)
What are people who design a hairdryer or an engine block?
"Should" is often used as a way to express advice, as in: "if you are a programmer and want to make more money, you should call yourself an engineer".
The HN title seems to be using a different definition of "should", or is perhaps expressing advice to those among us who don't care about money.
What others do I care less.
If they are doing engineering (with Hamilton being the first) they may. It's not a protected title thankfully. We are not in the middle ages anymore
You're just a hacker if you write a program which does the same thing and write it into an EEPROM.
1) Software Engineers should follow structured processes and methods to solve problems. They might look different: state charts, sequence diagrams, formal methods, SDLC etc. However, they often don't because expediency wins over correctness. Where it does matter such as process control systems, embedded systems, they do follow these processes rigorously.
2) That said, there are a lot of folks who may not be aware of these methods because they didn't receive formal training. That is the beauty of our field; you don't need somebody to certify you if you can invent solutions and solve problems. I will refer you to what happened to the author of strongtowns.org. https://www.strongtowns.org/journal/2023/1/30/lawsuit-update.... So, no, I beg to differ. We don't need a board of wise old men lording it over the rest of us.
3) We are conversing on, reading the article via, accessing content over the Internet. This is public infrastructure. Without the software engineers who invented/built BGP, TCP/IP, SNMP, etc., we would not be able to do this.