5 ms·

Why Computer Programmers Should Stop Calling Themselves Engineers

60 points by haZard_OS 9y ago

phs318u 9y ago
Agreed. 'Software engineers' are not actual engineers for the same reason that bridges and buildings don't come with an end-user license agreement that disclaims liability for a faulty product. "BY SETTING FOOT ON THE BRIDGE YOU ACKNOWLEDGE AND AGREE THAT THE BRIDGE IS PROVIDED ON AN 'AS IS' BASIS AND THAT YOUR USE AND RELIANCE ON THE BRIDGE THEREBY IS AT YOUR SOLE RISK AND DISCRETION. COMPANY AND ITS AFFILIATES, PARTNERS AND SUPPLIERS HEREBY DISCLAIM ANY AND ALL REPRESENTATIONS, WARRANTIES AND GUARANTIES REGARDING THE BRIDGE WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE. FURTHERMORE, COMPANY AND ITS AFFILIATES, PARTNERS AND SUPPLIERS MAKE NO WARRANTY THAT (I) THE BRIDGE WILL MEET YOUR REQUIREMENTS; (II) THE BRIDGE WILL BE STRUCTURALLY SOUND, RELIABLE, SECURE AND ERROR-FREE; (III) THE QUALITY OF THE BRIDGE WILL BE AS REPRESENTED OR MEET YOUR EXPECTATIONS; OR (IV) ANY FAULTS IN THE BRIDGE WILL BE CORRECTED."
- aerotwelve 9y ago
  THE FOLLOWING SETS FORTH ATTRIBUTION NOTICES FOR THIRD PARTY COMPONENTS THAT MAY BE CONTAINED IN PORTIONS OF THIS BRIDGE. WE THANK THE OPEN SOURCE COMMUNITY FOR ALL OF THEIR CONTRIBUTIONS.
jalberts72 9y ago
I completely agree with this. I have a degree in Electrical Engineering; however, I've chosen a career in technology. I've had titles like: systems engineer, devops engineer, build engineer, automation engineer. I've hated every one of those titles because I'm NOT an engineer. I explicitly chose not to follow the engineering path and instead start a career in technology. Funny thing is, any time I tell a coworker how I feel about being called an engineer, I just get a funny look.
- godelmachine 9y ago
  In your own words, would you kindly elaborate on the difference between engineering and technology?
- subway 9y ago
  Same boat. I'm still close friends with, and have mad respect for the folks who stuck with proper engineering when I realized that sort of work doesn't really align with the way I naturally think. They've demonstrated years of diligence in earning that steel ring.
  - sanderjd 9y ago
    I also have friends who I have mad respect for who are proper engineers and have demonstrated years of diligence in earning that steel ring. But I also have lots of programmer friends who have demonstrated years of diligence without there being any steel ring at the end to save them from programming on a white board every time they apply for a job. I think our way is better for talented but inexperienced young folks just breaking in, but worse for experienced folks whose years of success would have earned them a universally-respected credential in pretty much every other profession.
WheelsAtLarge 9y ago
There are Software Engineers but just because you are a Computer Programmer does not mean you are an Engineer. Engineers are defined as "individuals who uses scientific knowledge to solve practical problems." Most so-called engineers are software programmers. But Language is fluid and changes with time, so at this time "Software Engineer" is the term so it's no good fighting it.
- knome 9y ago
  > But Language is fluid and changes with time, so at this time "Software Engineer" is the term so it's no good fighting it. But language being fluid, fighting it seems perfectly reasonable.
  - timrichard 9y ago
    Sadly, I don't fancy your chances. It seems to be a lost cause when a small group of people want a huge group of people to revert to the original meaning of a word. Like 'decimated' and 'literally'.
- skookumchuck 9y ago
  As for changes in time, the term "engineer" used to mean the guy who drove the locomotive - and that guy didn't design the locomotive.
- avs733 9y ago
  The difference here is that, while language is very fluid, ENGINEER is a legally controlled term. Engineering as a profession has licensure- as does a doctor or nurse. There are potential legal consequences for calling oneself an engineer when one is not. There should be some effort to fight ambiguity masquerading as fluidity. They are not the same thing. This ambiguity literally got a child decapitated recently.
  - jack9 9y ago
    > ENGINEER is a legally controlled term. It's a classification, so I don't think that's so. "Driver" is an equivalent term.
psyc 9y ago
I've written this a dozen times, but 'software engineer' has pretty much never been a sub-category of engineer. It's a title internal to the software industry, and need not have any relation to Engineering beyond a metaphor. I genuinely don't understand why people find the distiction between a title and a kind of engineer such a problem. Why doesn't 'software architect' get the same criticism for not being an architect? If you're at work, everyone knows what 'software engineer' means. If you're at an engineering convention, don't call yourself an engineer unless you have the credentials. This title sometimes accompanies pretension toward traditional engineering, which is fine as far as it goes - usually not very far. I realize that there are some efforts in some jurisdictions to get something like engineering credentials for programmers. Ok, maybe that's not misguided, but I've yet to be convinced. It depends on how you conceptualize software. I don't think of it like engineering, I think of it like math. But more than that, I think of it as computer programming! If you think of it like engineering, I don't have a huge argument with that, but I have a hard time seeing is as more than an ill-fitting metaphor. I think that is one step better than the manufacturing metaphor.
- skookumchuck 9y ago
  > I don't think of it like engineering, I think of it like math. Ironic, considering that college engineering courses are about 95% math.
  - psyc 9y ago
    So's theoretical physics, and programming isn't that either. I partly mean that I think of it as still being the sub-field of mathematics it began as.
    - skookumchuck 9y ago
      I thought you were making the point that programming is math and engineering is not?
      - psyc 9y ago
kevinSuttle 9y ago
I’m not sure which is worse: “engineer”, or “architect”.
- skookumchuck 9y ago
  Who cares, what matters is which pays better :-)
skookumchuck 9y ago
It's true that software engineering doesn't require licenses like other engineers, and is not regulated unlike other engineering professions. But after that the article goes off the rails trying to draw a distinction. Programming above a certain level is engineering, just like being a mechanic above a certain level is engineering. Unregulated, unlicensed software engineering has also produced stupendous advances in programming in the last few decades, not remotely matched by advances in other heavily regulated and licensed professions.
- rjbwork 9y ago
  Seriously - I'm creating resources, connecting them together, gathering data on performance, adjusting sizes, bandwidths, re-engineering components that are degrading or insufficient for their purpose, etc. etc. etc. Yeah i'm programming to do some of that, but a lot of it involves building systems from infrastructure that don't fall over with a bunch of stuff gets put on top of it or goes through it. Sounds pretty dang engineery to me.
- zaksoup 9y ago
  Requirements for licenses and regulations of that sort almost always end up entrenching existing businesses more than they help consumers. I'm about as pro regulation as one can get but I'm always leery toward suggestions that licensing is what it would take for Software Engineering to be recognized as a 'real discipline' NPR has some fantastic reporting on licensing in the beauty industry and how it not only entrenches existing players but turned out to be really harmful to African American communities: https://www.npr.org/sections/money/2012/06/22/155596305/episode-381-why-its-illegal-to-braid-hair-without-a-license https://www.npr.org/sections/money/2012/06/22/155596305/epis...
- starpilot 9y ago
  > just like being a mechanic above a certain level is engineering And therein lies the confusion. There is no level at which a mechanic becomes an engineer. You can be both a mechanic and an engineer, but these are separate tracks with separate skills and training. A skilled mechanical engineer can be an inept mechanic, and vice versa. The fact that you don't understand traditional engineering shows why you consider programmers to be "engineers."
brianpan 9y ago
This is completely backwards to me. Instead of changing the name because it doesn't provide enough civic value, how about provide more civic value? Software is increasingly part of our infrastructure. The Internet is becoming utility. There are engineering companies of all sorts that are only trying to make a (zillion) bucks and not interested in "an explicit responsibility to public safety and reliability". This isn't unique to software.
- zaksoup 9y ago
  I really like this view. GetCalFresh[0] receives 30,000 applications for food stamps in 33 out of 58 counties in California each month. Not only is this absolutely a necessary utility but when it breaks or doesn't work the repercussions are far more sever than "somebody can't post a cat gif to reddit for a few hours". Plug for Code for America[1], if you're interested in civic tech and want to contribute reach out. We're hiring, and there's almost guaranteed to be a local brigade working on cool stuff near you. [0] https://www.getcalfresh.org https://www.getcalfresh.org [1] https://www.codeforamerica.org https://www.codeforamerica.org
andymoe 9y ago
We are building billion dollar software products that take hundreds or thousands of “man years”, with rigorous processes. So, respectfully, you can complain all you want but engineer is a fine title and description even if the software variety does not have the same gatekeepers you’re used to in other engineering fields.
- rjbwork 9y ago
  I don't generally tend towards such curtness but: rekt.
- lerax 9y ago
  https://www.youtube.com/watch?v=2dbR2JZmlWo https://www.youtube.com/watch?v=2dbR2JZmlWo
  - dang 9y ago
    Please don't do this here, even if someone else is wrong.
- cheschire 9y ago
  Perhaps some programmers are producing those products you describe but many of them are not. Programming is a vague term that seems to simply refer to the act of using a descriptive and functional language to describe a problem set intended to be solved by a computer. But then how is that different from any other area of applied mathematics? This ongoing debate seems needlessly pedantic. Someone will write some new academic paper, or book, or tweet which future generations will point back to and say "that was where the term computer humptyfucker came from to describe my job." A bunch of neckbeards will then buck the trend and start writing op-ed pieces about how we aren't humptyfuckers because we don't apply the rigidity that traditional certified and legal humptyfuckery requires.
- jcrites 9y ago
  Yep. Not all computer programmers are software engineers, but there definitely are software engineers. Building high-scale systems that also achieve high-availability with no maintenance windows yadda yadda is a challenging problem that requires navigating tradeoffs using scientific principles in the same way as other branches of engineering. Related: the article "They Write the Right Stuff", about the software engineers who worked on the Space Shuttle [1]. In the United States, the National Council of Examiners for Engineering and Surveying (NCEES), which is the organization of engineering licensing boards in all states, recognizes Software Engineering as a discipline of Professional Engineering [2]. Our industry does not ordinarily require certification as a professional engineer, and it is not normally required by law; however, if you look at the topics that the certification exam covers [3] -- intended for people with 4 years minimum industry experience -- they are all ones that I'd expect senior software engineers to have down pat. [1] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff [2] https://ncees.org/engineering/pe/software/ https://ncees.org/engineering/pe/software/ [3] https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pdf https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pd...
pishpash 9y ago
And data scientists are not really scientists.
- boznz 9y ago
  I call them Data Scientologists
- lerax 9y ago
  We are just Data Miners, with a hat for protection waiting to see a rock falling in our head... ouch, a comment did fall in my head. ~ so is this thing. You want hear a worse thing? Data Scientists thinking that are Mathematicians. All these titles are a joke. JavaScript Programmer is an insult, it should be only Browser API User.
alphabettsy 9y ago
There are certainly developers that are not doing any “engineering”, but as far as the software engineer title goes there are many cases where there is a distinction without a difference. Are the people working on autonomous driving, vehicle safety, infrastructure management any less important than the guy who designed the plastic housing with the title mechanical engineer?
- pishpash 9y ago
  Not less important, but not held to the same standard, which is the point here.
  - alphabettsy 9y ago
    That’s changing rapidly. The VW engineer that was charged with implementing a software defeat, the current Tesla controversy is entirely based on software, as is the woman killed by an Uber vehicle. As software becomes ever more a matter of life and death I think we’ll see software engineer used maybe more specifically. Maybe some or many programmers and developers should stop calling themselves engineers?
pishpash 9y ago
The term "software engineer" I believe came out of the engineering schools of various universities taking on CS disciplines and naming majors in this way. Anyway, by analogy to fintech and adtech, programmers should probably honestly style themselves as software technicians, unless they get themselves qualified as a real engineer.
skookumchuck 9y ago
One theme in the article is that regulated, licensed engineers don't produce buggy designs. Of course they do. Deepwater Horizon, Fukishima, to name a couple. Engineers produce buggy, bad designs everywhere you look. The reason bridges don't (usually) fall down is because most of them are copies of other successful designs, and because they are way overbuilt. I seem to recall a bridge collapsed just a couple months ago squashing cars and killing people. It was a new design.
- bostik 9y ago
  I am unsure about Fukushima being a buggy design. To me it has sounded more like mismanagement and negligence than anything else. Case in point - the plant disaster happened because the tsunami was higher than what the sea walls had been designed for. From what I have learned, Japan has plenty of evidence that magnitude-9 earthquakes and the following tsunamis have happened in the past. The protections in Fukushima (and Daichii) were designed against less. To fail under expected peak load is bad engineering. To ignore evidence and go with insufficient safety margins is something worse.
  - skookumchuck 9y ago
    There were numerous design errors that enabled the flooding to destroy the plant. For example, venting the hydrogen gas into an enclosed area, which resulted in an inevitable explosion. There's plenty more, if you read a step-by-step account of the disaster. Engineers iterate their designs based on past failures just like software engineers do. It's just that the life cycle is so much shorter for software, the iterations come thick and fast.
    - bostik 9y ago
      Thank you, those details definitely make a case of consistently bad engineering.
- iliaznk 9y ago
  And how about cars that get regularly called back over various hardware faults?
yawaramin 9y ago
The author seems to think that today's software is all created in short, barely-planned bursts of activity. They've heard of agile and scrum, and decided to lump everything together in there. The truth is there are high-assurance systems out there which go through extreme vetting and safety checks. Techniques like formal verification, model checking, and design by contract are all used to engineer safe systems. There's no doubt that, at a certain level of quality assurance, what software developers do is truly engineering.
- pishpash 9y ago
  And how much of each is there? Some of the most important software infrastructures were built years ago at the dawn of computing (telephone, banking, etc.) when experts and artisans ruled the field. Now anybody who does a few weeks of bootcamp or watches some online videos calls themselves an engineer and pushes out crap code to the masses.
- psyc 9y ago
  I'm generally opposed to the software-as-engineering metaphor, but I actually agree with what you're saying here. The problem is that in 20 years, I've never worked on a team that came within 100 miles of what you're describing. On every team I've been on, at software companies of all sizes, it goes like this: "I like SOLID." "No, I don't like SOLID." "I think exceptions should only be thrown in truly exceptional circumstances." "No, I think you should throw at the faintest whiff of the unexpected." "I like short methods." "No, I like long methods. You can see the whole flow." And so on. And the resulting standard for the team might as well be chosen by coin flips.
kevintb 9y ago
Most software "engineers" barely think about the societal consequences of their work, and CS students have no "do-no-harm" oath that engineers have to take. I would say that in comparison to engineers who build things for public interest (infrastructure that can kill people), physicists (history of the nuclear bomb), biologists (unethical medical experimentation from WWII), etc ... software engineers barely think about societal consequences of their actions the way other scientific professions do.
alacombe 9y ago
Why am I an Engineer ? Because my school, based in Europe, is accredited to deliver a proper recognized engineering degree. Last time I check, I could get a P.Eng (proper engineer order here in Canada), but don't see the point forking the $400 annual subscription.
deleted 9y ago
[deleted]
textmode 9y ago
Related question: I was wondering about the origin of the usage of the term "build" when programmers describe what they do. To be clear, I am not referring to "build" as in compiling, assembling and linking to "build" binaries, but "build" as used in statements such as "I like to build stuff." I believe it may have originated from a 1993 book called "Code Complete". This book used a "construction" metaphor to describe programming. This is only a guess.
nickpsecurity 9y ago
What most programmers do isn't engineering. However, there are programmers that do engineering. Here's two that were used to make software that was consistently low-defect that sometimes came with warranties. I picked them since they had acceptable cost/timing vs the methods with full, formal verification. http://infohost.nmt.edu/~al/cseet-paper.html http://infohost.nmt.edu/~al/cseet-paper.html http://www.anthonyhall.org/c_by_c_secure_system.pdf http://www.anthonyhall.org/c_by_c_secure_system.pdf
- irundebian 9y ago
  Hi nickpsecurity, I always like your posts, that's why I bookmarked your comments page and check it every few days for changes. What stands out, that these papers and articles are pretty old. It seems to me that these are pretty academic examples. I don't understand why we can't see a lot of software in the wild, following the state of the art practices of building secure software. Maybe these practices are still relatively impracticable to the average programmer. Maybe research on secure software development should check their ideas more for psychological acceptability (Saltzer/Schröder).
  - nickpsecurity 9y ago
    Glad you enjoy it. If you like that kind of stuff, you should keep an eye on Lobste.rs since I submit most of the CompSci stuff there. Mainly because they like it more over there but some people occasionally build on it. Mostly about formal methods filtered down to most interesting work but also do other stuff here and there. Here's a link to my submissions if you want to go through them: https://lobste.rs/newest/nickpsecurity https://lobste.rs/newest/nickpsecurity Far as old, it's important to remember that many things we're doing today started in some form a long time ago. Certain principles are timeless. For instance, the Burroughs B5000 was checking for overflows and argument matching on every operation at the CPU level back in 1961. That thing was immune to common, coding attacks until maybe when ROP was invented. The newer thing was C language designed for efficiency on weaker hardware. People still argue today if we can defeat the vulnerabilities in our legacy systems without realizing some in 60's-80's were immune to them. Occasionally, a current team will learn from or reinvent that older research to find it's still useful like crash-safe.org and Cambridge's CHERI did for secure CPU's w/ CHERI running FreeBSD. So, don't judge by age: look at what was done, why it worked, why it would/wouldn't today, if changes in context matter, and esp how practical it might be. Far as that, Cleanroom worked even on first try on real projects for commercial teams and students. I just got the book recently where I'll be trying it sometime in near future. It looks pretty good so far with it just being careful structuring and thinking about things in algebraic way. Why did it disappear? Likely bandwagon effect where some New Great Method got popular like it did, displaced it as project managers wanted to look like they were doing something new, and now it's a relic of history. Lots of stuff like that. Happens more if there's big companies with enterprise tooling backing the newcomers like the 4GL's, UML, etc. Even more when tool promises to remove human from equation as much as possible vs Cleanroom that built on human talent (i.e. time). Now, SPARK is entirely different. I got that book, too. :) It was always marketed at a niche group of people building stuff that should never fail. They have to be willing to spend a lot of time using specialist techniques to make that happen. They also must do it in non-mainstream language with proprietary tooling. Needless to say, adoption was small. However, AdaCore's site shows quite a few companies are using it in safety-critical work. I also have some case studies in my Lobsters submissions involving SPARK with keywords being "SPARK," "glider," and "cubesat" if you want to try to just Google them. Altran Praxis, who originally developed it, has been using it in government and commercial projects for one or two decades. The book supposedly makes it easier. I figure a combo of spec-based tests, automated solving, and runtime checks for what's left is still gonna be easiest approach. Aside from those two, another nice example is Design-by-Contract which is quite accessible to average developer. It just says what the component expects to receive, maintain, and deliver. That can be turned into tests, runtime checks, or verification conditions for a prover. One can also combine the runtime checks with fuzzing like AFL to make it zero in on the specific error. Eiffel Method brought that to significant adoption in industry even though small in larger scheme of things. We have seen increased adoption of some of those principles with more contract implementations in mainstream languages and property-based testing getting popular. Anyway, here's a nice description of that I saved as much for managers as developers: https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-by-contract/index.html https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-b... "Maybe research on secure software development should check their ideas more for psychological acceptability (Saltzer/Schröder)." Oh, I've learned so much about this angle. I couldn't begin to tell you. Mostly pessimistic but there's some hope. We've been solving the wrong problems. Most of the security problem comes from political maneuverings through lobbyists, market preferences which rarely value security, and business incentives that are similar. There's strategies for each which have potential. My best hypothesis for now is to keep pushing methods that are productive with the tech designed for verification [later] with lightweight methods used up front. You sell the approach as much as possible on non-security benefits with a certain amount of money funneled into improving security of the project or its dependencies. Rinse repeat. Also, better to invest in projects that improve security on things with same language, API, ISA, etc as things with huge, bandwagon effects. Gotta go with the flow.
mnm1 9y ago
Where software is highly regulated, it is of much higher quality. This article is so badly researched, they use the example of a late model car starting reliably as an example of good engineering. Well then, I suppose the people who wrote the millions of lines of code that run that car shouldn't be called engineers either. Or should they? Clearly the article's author is too stupid to understand the technology. What about people who write airplane software? If this idiotic author doesn't want bugs in his Google docs, he should be pushing to regulate such software in the same way that airplane software is regulated. Sure, it doesn't make sense to do that. What would make sense is to realize that regulations and laws are the only difference between flight software and some buggy internet app. If you remove regulations from flight software and car software, planes and cars will crash and kill. At least Google docs might only lose your document in the worst case scenario. And don't even get me started on the outrage of train engineers at their title being co-opted. /s
bribroder 9y ago
Why Journalists Should Stop Calling Themselves Writers
- notacoward 9y ago
  Why Academic Hacks Should Stop Calling Themselves Journalists
AdieuToLogic 9y ago
Engineering is a discipline in which new endevours are undertaken with repeatable processes defined by the knowledge and experience learned from previous engineers' efforts in the same domain, codified in "professional standards." For problem domains whose solutions are manifest in well-known artifacts, such as bridges and buildings, these standards have been established over several centuries. Still, failures persist which cause refinement in said standards, though at a low enough frequency where the failures now are seen as aberrant conditions. Where software practitioners study the techniques and/or practices reified by accomplished predecessors, assimilate lessons learned from the practitioner's own efforts/failures, and refine a documented repeatable approach that incorporates the aforementioned, there is little cause to refute the title of "software engineer."
gcommer 9y ago
The author arbitrarily decides on "number of failures" as their measure of reliability, as opposed to a much more reasonable "number of failures" * "mean cost of failure". There is also no attempt to correct for the confirmation bias of software being so popular, no attempt to present non-anecdotal evidence, and no attempt to provide comparative data for other engineering disciplines.
finnthehuman 9y ago
> “I’m not a programmer,[] —oh, engineer, in tech-bro speak. Though to me, engineers are people who build bridges and follow pretty rigid processes for a reason.” His indictment touches a nerve. No shit it touches a nerve. It's cliché both in sentiment and presentation. No laboratory could design a sentence more tailor-made to light up an American-left cultural-critic writer's brain. It's almost a work of art that in so few words the speaker postured themselves, namecheked this week's scapegoat and even snuck in a bit of a humble-brag.
himom 9y ago
A programmer is a computer code writer. A software engineer aims to be a more efficient, elegant and scientific programmer.
threatofrain 9y ago
The requirement that engineers be related to the public interest is wrong. No more than the petroleum engineer is obligated to think of the ecology or energy politics. And when there are big oil spills, I doubt it's extra criticism about engineering obligations that will do the trick, as opposed to billion dollar penalties. Engineers often don't own priorities. So as long as the people who set company priorities don't care, nobody will either. Moral yelling won't disrupt a business model, and if neither consumers nor legislators punish companies for spilling externalities around, then what do companies care? If the activity continues to be profitable...
koonsolo 9y ago
> Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver I think this is really funny, because I worked with actual engineers on multiple projects. The 'real programmers', or however you want to call them, had to clean up their mess and introduce proper standards and processes. I also worked with some good engineers, so I'm not claiming they are all that bad. But stuff that I saw from real engineers: - Express distance in some unknown number (we called it 'werners' because that guy was called Werner). We introduced mm. - Instead of copy pasting parts of previous projects (going on for about 20 projects), we made a reusable library. - Disabled/circumvented safety system on a robot. We were all amazed. - Release things untested to end users. We tried to convince them to hire a tester, didn't work. So we tested our own stuff a bit better, but never officially got time for that. So please leave the snarky comments that 'real engineers' are somehow better than us mortal coders. Any decent coder who worked with real engineers can tell you that the difference is not really there. It's not the people or processes or whatever. Writing software cannot really be compared to anything else.
itsmejeff 9y ago
This article climbs the HN ranks once every few months... I'm a "real" engineer who chose to make my career in software. There are obviously things that this author does not know about software engineering and there are things that software engineers don't know about "traditional" engineering. Both have their strengths and weaknesses. Everybody chill out
mattykay 9y ago
I guess Atlantic doesn't need that website it software it runs to reliably help them do their business and make money...
timrichard 9y ago
Even though my degree certificate says "....Software Engineering", I usually refer to myself as a Software Developer. Mostly to avoid any tedious arguments with mystic folk that have sacred oaths and magic rings. But it is noticeable that when a commercial lift/elevator or Espresso machine develops a fault, people quite casually say that "an engineer is on the way" and nobody bats an eyelid. Don't most software bugs require a much deeper diagnosis and more elaborate fix?

60 points by haZard_OS 9y ago

Agreed. 'Software engineers' are not actual engineers for the same reason that bridges and buildings don't come with an end-user license agreement that disclaims liability for a faulty product. "BY SETTING FOOT ON THE BRIDGE YOU ACKNOWLEDGE AND AGREE THAT THE BRIDGE IS PROVIDED ON AN 'AS IS' BASIS AND THAT YOUR USE AND RELIANCE ON THE BRIDGE THEREBY IS AT YOUR SOLE RISK AND DISCRETION. COMPANY AND ITS AFFILIATES, PARTNERS AND SUPPLIERS HEREBY DISCLAIM ANY AND ALL REPRESENTATIONS, WARRANTIES AND GUARANTIES REGARDING THE BRIDGE WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE. FURTHERMORE, COMPANY AND ITS AFFILIATES, PARTNERS AND SUPPLIERS MAKE NO WARRANTY THAT (I) THE BRIDGE WILL MEET YOUR REQUIREMENTS; (II) THE BRIDGE WILL BE STRUCTURALLY SOUND, RELIABLE, SECURE AND ERROR-FREE; (III) THE QUALITY OF THE BRIDGE WILL BE AS REPRESENTED OR MEET YOUR EXPECTATIONS; OR (IV) ANY FAULTS IN THE BRIDGE WILL BE CORRECTED."

aerotwelve 9y ago
THE FOLLOWING SETS FORTH ATTRIBUTION NOTICES FOR THIRD PARTY COMPONENTS THAT MAY BE CONTAINED IN PORTIONS OF THIS BRIDGE. WE THANK THE OPEN SOURCE COMMUNITY FOR ALL OF THEIR CONTRIBUTIONS.

jalberts72 9y ago

I completely agree with this. I have a degree in Electrical Engineering; however, I've chosen a career in technology. I've had titles like: systems engineer, devops engineer, build engineer, automation engineer. I've hated every one of those titles because I'm NOT an engineer. I explicitly chose not to follow the engineering path and instead start a career in technology. Funny thing is, any time I tell a coworker how I feel about being called an engineer, I just get a funny look.

godelmachine 9y ago
In your own words, would you kindly elaborate on the difference between engineering and technology?
subway 9y ago
Same boat. I'm still close friends with, and have mad respect for the folks who stuck with proper engineering when I realized that sort of work doesn't really align with the way I naturally think. They've demonstrated years of diligence in earning that steel ring.
- sanderjd 9y ago
  I also have friends who I have mad respect for who are proper engineers and have demonstrated years of diligence in earning that steel ring. But I also have lots of programmer friends who have demonstrated years of diligence without there being any steel ring at the end to save them from programming on a white board every time they apply for a job. I think our way is better for talented but inexperienced young folks just breaking in, but worse for experienced folks whose years of success would have earned them a universally-respected credential in pretty much every other profession.

WheelsAtLarge 9y ago

There are Software Engineers but just because you are a Computer Programmer does not mean you are an Engineer. Engineers are defined as "individuals who uses scientific knowledge to solve practical problems." Most so-called engineers are software programmers. But Language is fluid and changes with time, so at this time "Software Engineer" is the term so it's no good fighting it.

knome 9y ago
> But Language is fluid and changes with time, so at this time "Software Engineer" is the term so it's no good fighting it. But language being fluid, fighting it seems perfectly reasonable.
- timrichard 9y ago
  Sadly, I don't fancy your chances. It seems to be a lost cause when a small group of people want a huge group of people to revert to the original meaning of a word. Like 'decimated' and 'literally'.
skookumchuck 9y ago
As for changes in time, the term "engineer" used to mean the guy who drove the locomotive - and that guy didn't design the locomotive.
avs733 9y ago
The difference here is that, while language is very fluid, ENGINEER is a legally controlled term. Engineering as a profession has licensure- as does a doctor or nurse. There are potential legal consequences for calling oneself an engineer when one is not. There should be some effort to fight ambiguity masquerading as fluidity. They are not the same thing. This ambiguity literally got a child decapitated recently.
- jack9 9y ago
  > ENGINEER is a legally controlled term. It's a classification, so I don't think that's so. "Driver" is an equivalent term.

psyc 9y ago

I've written this a dozen times, but 'software engineer' has pretty much never been a sub-category of engineer. It's a title internal to the software industry, and need not have any relation to Engineering beyond a metaphor. I genuinely don't understand why people find the distiction between a title and a kind of engineer such a problem. Why doesn't 'software architect' get the same criticism for not being an architect? If you're at work, everyone knows what 'software engineer' means. If you're at an engineering convention, don't call yourself an engineer unless you have the credentials. This title sometimes accompanies pretension toward traditional engineering, which is fine as far as it goes - usually not very far. I realize that there are some efforts in some jurisdictions to get something like engineering credentials for programmers. Ok, maybe that's not misguided, but I've yet to be convinced. It depends on how you conceptualize software. I don't think of it like engineering, I think of it like math. But more than that, I think of it as computer programming! If you think of it like engineering, I don't have a huge argument with that, but I have a hard time seeing is as more than an ill-fitting metaphor. I think that is one step better than the manufacturing metaphor.

skookumchuck 9y ago
> I don't think of it like engineering, I think of it like math. Ironic, considering that college engineering courses are about 95% math.
- psyc 9y ago
  So's theoretical physics, and programming isn't that either. I partly mean that I think of it as still being the sub-field of mathematics it began as.
  - skookumchuck 9y ago
    I thought you were making the point that programming is math and engineering is not?
    - psyc 9y ago

kevinSuttle 9y ago

I’m not sure which is worse: “engineer”, or “architect”.

skookumchuck 9y ago
Who cares, what matters is which pays better :-)

skookumchuck 9y ago

It's true that software engineering doesn't require licenses like other engineers, and is not regulated unlike other engineering professions. But after that the article goes off the rails trying to draw a distinction. Programming above a certain level is engineering, just like being a mechanic above a certain level is engineering. Unregulated, unlicensed software engineering has also produced stupendous advances in programming in the last few decades, not remotely matched by advances in other heavily regulated and licensed professions.

rjbwork 9y ago
Seriously - I'm creating resources, connecting them together, gathering data on performance, adjusting sizes, bandwidths, re-engineering components that are degrading or insufficient for their purpose, etc. etc. etc. Yeah i'm programming to do some of that, but a lot of it involves building systems from infrastructure that don't fall over with a bunch of stuff gets put on top of it or goes through it. Sounds pretty dang engineery to me.
zaksoup 9y ago
Requirements for licenses and regulations of that sort almost always end up entrenching existing businesses more than they help consumers. I'm about as pro regulation as one can get but I'm always leery toward suggestions that licensing is what it would take for Software Engineering to be recognized as a 'real discipline' NPR has some fantastic reporting on licensing in the beauty industry and how it not only entrenches existing players but turned out to be really harmful to African American communities: https://www.npr.org/sections/money/2012/06/22/155596305/episode-381-why-its-illegal-to-braid-hair-without-a-license https://www.npr.org/sections/money/2012/06/22/155596305/epis...
starpilot 9y ago
> just like being a mechanic above a certain level is engineering And therein lies the confusion. There is no level at which a mechanic becomes an engineer. You can be both a mechanic and an engineer, but these are separate tracks with separate skills and training. A skilled mechanical engineer can be an inept mechanic, and vice versa. The fact that you don't understand traditional engineering shows why you consider programmers to be "engineers."

brianpan 9y ago

This is completely backwards to me. Instead of changing the name because it doesn't provide enough civic value, how about provide more civic value? Software is increasingly part of our infrastructure. The Internet is becoming utility. There are engineering companies of all sorts that are only trying to make a (zillion) bucks and not interested in "an explicit responsibility to public safety and reliability". This isn't unique to software.

zaksoup 9y ago
I really like this view. GetCalFresh[0] receives 30,000 applications for food stamps in 33 out of 58 counties in California each month. Not only is this absolutely a necessary utility but when it breaks or doesn't work the repercussions are far more sever than "somebody can't post a cat gif to reddit for a few hours". Plug for Code for America[1], if you're interested in civic tech and want to contribute reach out. We're hiring, and there's almost guaranteed to be a local brigade working on cool stuff near you. [0] https://www.getcalfresh.org https://www.getcalfresh.org [1] https://www.codeforamerica.org https://www.codeforamerica.org

andymoe 9y ago

We are building billion dollar software products that take hundreds or thousands of “man years”, with rigorous processes. So, respectfully, you can complain all you want but engineer is a fine title and description even if the software variety does not have the same gatekeepers you’re used to in other engineering fields.

rjbwork 9y ago
I don't generally tend towards such curtness but: rekt.
lerax 9y ago
https://www.youtube.com/watch?v=2dbR2JZmlWo https://www.youtube.com/watch?v=2dbR2JZmlWo
- dang 9y ago
  Please don't do this here, even if someone else is wrong.
cheschire 9y ago
Perhaps some programmers are producing those products you describe but many of them are not. Programming is a vague term that seems to simply refer to the act of using a descriptive and functional language to describe a problem set intended to be solved by a computer. But then how is that different from any other area of applied mathematics? This ongoing debate seems needlessly pedantic. Someone will write some new academic paper, or book, or tweet which future generations will point back to and say "that was where the term computer humptyfucker came from to describe my job." A bunch of neckbeards will then buck the trend and start writing op-ed pieces about how we aren't humptyfuckers because we don't apply the rigidity that traditional certified and legal humptyfuckery requires.
jcrites 9y ago
Yep. Not all computer programmers are software engineers, but there definitely are software engineers. Building high-scale systems that also achieve high-availability with no maintenance windows yadda yadda is a challenging problem that requires navigating tradeoffs using scientific principles in the same way as other branches of engineering. Related: the article "They Write the Right Stuff", about the software engineers who worked on the Space Shuttle [1]. In the United States, the National Council of Examiners for Engineering and Surveying (NCEES), which is the organization of engineering licensing boards in all states, recognizes Software Engineering as a discipline of Professional Engineering [2]. Our industry does not ordinarily require certification as a professional engineer, and it is not normally required by law; however, if you look at the topics that the certification exam covers [3] -- intended for people with 4 years minimum industry experience -- they are all ones that I'd expect senior software engineers to have down pat. [1] https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff [2] https://ncees.org/engineering/pe/software/ https://ncees.org/engineering/pe/software/ [3] https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pdf https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pd...

pishpash 9y ago

And data scientists are not really scientists.

boznz 9y ago
I call them Data Scientologists
lerax 9y ago
We are just Data Miners, with a hat for protection waiting to see a rock falling in our head... ouch, a comment did fall in my head. ~ so is this thing. You want hear a worse thing? Data Scientists thinking that are Mathematicians. All these titles are a joke. JavaScript Programmer is an insult, it should be only Browser API User.

alphabettsy 9y ago

There are certainly developers that are not doing any “engineering”, but as far as the software engineer title goes there are many cases where there is a distinction without a difference. Are the people working on autonomous driving, vehicle safety, infrastructure management any less important than the guy who designed the plastic housing with the title mechanical engineer?

pishpash 9y ago
Not less important, but not held to the same standard, which is the point here.
- alphabettsy 9y ago
  That’s changing rapidly. The VW engineer that was charged with implementing a software defeat, the current Tesla controversy is entirely based on software, as is the woman killed by an Uber vehicle. As software becomes ever more a matter of life and death I think we’ll see software engineer used maybe more specifically. Maybe some or many programmers and developers should stop calling themselves engineers?

pishpash 9y ago

The term "software engineer" I believe came out of the engineering schools of various universities taking on CS disciplines and naming majors in this way. Anyway, by analogy to fintech and adtech, programmers should probably honestly style themselves as software technicians, unless they get themselves qualified as a real engineer.

skookumchuck 9y ago

One theme in the article is that regulated, licensed engineers don't produce buggy designs. Of course they do. Deepwater Horizon, Fukishima, to name a couple. Engineers produce buggy, bad designs everywhere you look. The reason bridges don't (usually) fall down is because most of them are copies of other successful designs, and because they are way overbuilt. I seem to recall a bridge collapsed just a couple months ago squashing cars and killing people. It was a new design.

bostik 9y ago
I am unsure about Fukushima being a buggy design. To me it has sounded more like mismanagement and negligence than anything else. Case in point - the plant disaster happened because the tsunami was higher than what the sea walls had been designed for. From what I have learned, Japan has plenty of evidence that magnitude-9 earthquakes and the following tsunamis have happened in the past. The protections in Fukushima (and Daichii) were designed against less. To fail under expected peak load is bad engineering. To ignore evidence and go with insufficient safety margins is something worse.
- skookumchuck 9y ago
  There were numerous design errors that enabled the flooding to destroy the plant. For example, venting the hydrogen gas into an enclosed area, which resulted in an inevitable explosion. There's plenty more, if you read a step-by-step account of the disaster. Engineers iterate their designs based on past failures just like software engineers do. It's just that the life cycle is so much shorter for software, the iterations come thick and fast.
  - bostik 9y ago
    Thank you, those details definitely make a case of consistently bad engineering.
iliaznk 9y ago
And how about cars that get regularly called back over various hardware faults?

yawaramin 9y ago

The author seems to think that today's software is all created in short, barely-planned bursts of activity. They've heard of agile and scrum, and decided to lump everything together in there. The truth is there are high-assurance systems out there which go through extreme vetting and safety checks. Techniques like formal verification, model checking, and design by contract are all used to engineer safe systems. There's no doubt that, at a certain level of quality assurance, what software developers do is truly engineering.

pishpash 9y ago
And how much of each is there? Some of the most important software infrastructures were built years ago at the dawn of computing (telephone, banking, etc.) when experts and artisans ruled the field. Now anybody who does a few weeks of bootcamp or watches some online videos calls themselves an engineer and pushes out crap code to the masses.
psyc 9y ago
I'm generally opposed to the software-as-engineering metaphor, but I actually agree with what you're saying here. The problem is that in 20 years, I've never worked on a team that came within 100 miles of what you're describing. On every team I've been on, at software companies of all sizes, it goes like this: "I like SOLID." "No, I don't like SOLID." "I think exceptions should only be thrown in truly exceptional circumstances." "No, I think you should throw at the faintest whiff of the unexpected." "I like short methods." "No, I like long methods. You can see the whole flow." And so on. And the resulting standard for the team might as well be chosen by coin flips.

kevintb 9y ago

Most software "engineers" barely think about the societal consequences of their work, and CS students have no "do-no-harm" oath that engineers have to take. I would say that in comparison to engineers who build things for public interest (infrastructure that can kill people), physicists (history of the nuclear bomb), biologists (unethical medical experimentation from WWII), etc ... software engineers barely think about societal consequences of their actions the way other scientific professions do.

alacombe 9y ago

Why am I an Engineer ? Because my school, based in Europe, is accredited to deliver a proper recognized engineering degree. Last time I check, I could get a P.Eng (proper engineer order here in Canada), but don't see the point forking the $400 annual subscription.

deleted 9y ago

[deleted]

textmode 9y ago

Related question: I was wondering about the origin of the usage of the term "build" when programmers describe what they do. To be clear, I am not referring to "build" as in compiling, assembling and linking to "build" binaries, but "build" as used in statements such as "I like to build stuff." I believe it may have originated from a 1993 book called "Code Complete". This book used a "construction" metaphor to describe programming. This is only a guess.

nickpsecurity 9y ago

What most programmers do isn't engineering. However, there are programmers that do engineering. Here's two that were used to make software that was consistently low-defect that sometimes came with warranties. I picked them since they had acceptable cost/timing vs the methods with full, formal verification. http://infohost.nmt.edu/~al/cseet-paper.html http://infohost.nmt.edu/~al/cseet-paper.html http://www.anthonyhall.org/c_by_c_secure_system.pdf http://www.anthonyhall.org/c_by_c_secure_system.pdf

irundebian 9y ago
Hi nickpsecurity, I always like your posts, that's why I bookmarked your comments page and check it every few days for changes. What stands out, that these papers and articles are pretty old. It seems to me that these are pretty academic examples. I don't understand why we can't see a lot of software in the wild, following the state of the art practices of building secure software. Maybe these practices are still relatively impracticable to the average programmer. Maybe research on secure software development should check their ideas more for psychological acceptability (Saltzer/Schröder).
- nickpsecurity 9y ago
  Glad you enjoy it. If you like that kind of stuff, you should keep an eye on Lobste.rs since I submit most of the CompSci stuff there. Mainly because they like it more over there but some people occasionally build on it. Mostly about formal methods filtered down to most interesting work but also do other stuff here and there. Here's a link to my submissions if you want to go through them: https://lobste.rs/newest/nickpsecurity https://lobste.rs/newest/nickpsecurity Far as old, it's important to remember that many things we're doing today started in some form a long time ago. Certain principles are timeless. For instance, the Burroughs B5000 was checking for overflows and argument matching on every operation at the CPU level back in 1961. That thing was immune to common, coding attacks until maybe when ROP was invented. The newer thing was C language designed for efficiency on weaker hardware. People still argue today if we can defeat the vulnerabilities in our legacy systems without realizing some in 60's-80's were immune to them. Occasionally, a current team will learn from or reinvent that older research to find it's still useful like crash-safe.org and Cambridge's CHERI did for secure CPU's w/ CHERI running FreeBSD. So, don't judge by age: look at what was done, why it worked, why it would/wouldn't today, if changes in context matter, and esp how practical it might be. Far as that, Cleanroom worked even on first try on real projects for commercial teams and students. I just got the book recently where I'll be trying it sometime in near future. It looks pretty good so far with it just being careful structuring and thinking about things in algebraic way. Why did it disappear? Likely bandwagon effect where some New Great Method got popular like it did, displaced it as project managers wanted to look like they were doing something new, and now it's a relic of history. Lots of stuff like that. Happens more if there's big companies with enterprise tooling backing the newcomers like the 4GL's, UML, etc. Even more when tool promises to remove human from equation as much as possible vs Cleanroom that built on human talent (i.e. time). Now, SPARK is entirely different. I got that book, too. :) It was always marketed at a niche group of people building stuff that should never fail. They have to be willing to spend a lot of time using specialist techniques to make that happen. They also must do it in non-mainstream language with proprietary tooling. Needless to say, adoption was small. However, AdaCore's site shows quite a few companies are using it in safety-critical work. I also have some case studies in my Lobsters submissions involving SPARK with keywords being "SPARK," "glider," and "cubesat" if you want to try to just Google them. Altran Praxis, who originally developed it, has been using it in government and commercial projects for one or two decades. The book supposedly makes it easier. I figure a combo of spec-based tests, automated solving, and runtime checks for what's left is still gonna be easiest approach. Aside from those two, another nice example is Design-by-Contract which is quite accessible to average developer. It just says what the component expects to receive, maintain, and deliver. That can be turned into tests, runtime checks, or verification conditions for a prover. One can also combine the runtime checks with fuzzing like AFL to make it zero in on the specific error. Eiffel Method brought that to significant adoption in industry even though small in larger scheme of things. We have seen increased adoption of some of those principles with more contract implementations in mainstream languages and property-based testing getting popular. Anyway, here's a nice description of that I saved as much for managers as developers: https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-by-contract/index.html https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-b... "Maybe research on secure software development should check their ideas more for psychological acceptability (Saltzer/Schröder)." Oh, I've learned so much about this angle. I couldn't begin to tell you. Mostly pessimistic but there's some hope. We've been solving the wrong problems. Most of the security problem comes from political maneuverings through lobbyists, market preferences which rarely value security, and business incentives that are similar. There's strategies for each which have potential. My best hypothesis for now is to keep pushing methods that are productive with the tech designed for verification [later] with lightweight methods used up front. You sell the approach as much as possible on non-security benefits with a certain amount of money funneled into improving security of the project or its dependencies. Rinse repeat. Also, better to invest in projects that improve security on things with same language, API, ISA, etc as things with huge, bandwagon effects. Gotta go with the flow.

mnm1 9y ago

Where software is highly regulated, it is of much higher quality. This article is so badly researched, they use the example of a late model car starting reliably as an example of good engineering. Well then, I suppose the people who wrote the millions of lines of code that run that car shouldn't be called engineers either. Or should they? Clearly the article's author is too stupid to understand the technology. What about people who write airplane software? If this idiotic author doesn't want bugs in his Google docs, he should be pushing to regulate such software in the same way that airplane software is regulated. Sure, it doesn't make sense to do that. What would make sense is to realize that regulations and laws are the only difference between flight software and some buggy internet app. If you remove regulations from flight software and car software, planes and cars will crash and kill. At least Google docs might only lose your document in the worst case scenario. And don't even get me started on the outrage of train engineers at their title being co-opted. /s

bribroder 9y ago

Why Journalists Should Stop Calling Themselves Writers

notacoward 9y ago
Why Academic Hacks Should Stop Calling Themselves Journalists

AdieuToLogic 9y ago

Engineering is a discipline in which new endevours are undertaken with repeatable processes defined by the knowledge and experience learned from previous engineers' efforts in the same domain, codified in "professional standards." For problem domains whose solutions are manifest in well-known artifacts, such as bridges and buildings, these standards have been established over several centuries. Still, failures persist which cause refinement in said standards, though at a low enough frequency where the failures now are seen as aberrant conditions. Where software practitioners study the techniques and/or practices reified by accomplished predecessors, assimilate lessons learned from the practitioner's own efforts/failures, and refine a documented repeatable approach that incorporates the aforementioned, there is little cause to refute the title of "software engineer."

gcommer 9y ago

The author arbitrarily decides on "number of failures" as their measure of reliability, as opposed to a much more reasonable "number of failures" * "mean cost of failure". There is also no attempt to correct for the confirmation bias of software being so popular, no attempt to present non-anecdotal evidence, and no attempt to provide comparative data for other engineering disciplines.

finnthehuman 9y ago

> “I’m not a programmer,[] —oh, engineer, in tech-bro speak. Though to me, engineers are people who build bridges and follow pretty rigid processes for a reason.” His indictment touches a nerve. No shit it touches a nerve. It's cliché both in sentiment and presentation. No laboratory could design a sentence more tailor-made to light up an American-left cultural-critic writer's brain. It's almost a work of art that in so few words the speaker postured themselves, namecheked this week's scapegoat and even snuck in a bit of a humble-brag.

himom 9y ago

A programmer is a computer code writer. A software engineer aims to be a more efficient, elegant and scientific programmer.

threatofrain 9y ago

The requirement that engineers be related to the public interest is wrong. No more than the petroleum engineer is obligated to think of the ecology or energy politics. And when there are big oil spills, I doubt it's extra criticism about engineering obligations that will do the trick, as opposed to billion dollar penalties. Engineers often don't own priorities. So as long as the people who set company priorities don't care, nobody will either. Moral yelling won't disrupt a business model, and if neither consumers nor legislators punish companies for spilling externalities around, then what do companies care? If the activity continues to be profitable...

koonsolo 9y ago

> Engineering claims an explicit responsibility to public safety and reliability, even if it doesn’t always deliver I think this is really funny, because I worked with actual engineers on multiple projects. The 'real programmers', or however you want to call them, had to clean up their mess and introduce proper standards and processes. I also worked with some good engineers, so I'm not claiming they are all that bad. But stuff that I saw from real engineers: - Express distance in some unknown number (we called it 'werners' because that guy was called Werner). We introduced mm. - Instead of copy pasting parts of previous projects (going on for about 20 projects), we made a reusable library. - Disabled/circumvented safety system on a robot. We were all amazed. - Release things untested to end users. We tried to convince them to hire a tester, didn't work. So we tested our own stuff a bit better, but never officially got time for that. So please leave the snarky comments that 'real engineers' are somehow better than us mortal coders. Any decent coder who worked with real engineers can tell you that the difference is not really there. It's not the people or processes or whatever. Writing software cannot really be compared to anything else.

itsmejeff 9y ago

This article climbs the HN ranks once every few months... I'm a "real" engineer who chose to make my career in software. There are obviously things that this author does not know about software engineering and there are things that software engineers don't know about "traditional" engineering. Both have their strengths and weaknesses. Everybody chill out

mattykay 9y ago

I guess Atlantic doesn't need that website it software it runs to reliably help them do their business and make money...

timrichard 9y ago

Even though my degree certificate says "....Software Engineering", I usually refer to myself as a Software Developer. Mostly to avoid any tedious arguments with mystic folk that have sacred oaths and magic rings. But it is noticeable that when a commercial lift/elevator or Espresso machine develops a fault, people quite casually say that "an engineer is on the way" and nobody bats an eyelid. Don't most software bugs require a much deeper diagnosis and more elaborate fix?