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.
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.
NCEES is discontinuing the PE Software exam because fewer than 100 people have ever taken it. In my experience, maybe 10% of people in the field have even heard of it, and most of them think it's useless.
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.
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."
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.
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.
> Why doesn't 'software architect' get the same criticism for not being an architect?
I'm married to an Architect, it bugs them too.
In most states - Legally they can't call themselves Architects until they've passed the AREs. You can't take the AREs until you have enough IDP hours (which takes about 3 years). You can't start IDP unless you have a Masters (or more recently a "professional bachelors"). Oh, and you have to take a new test for every state / country you want to practice Architecture in (Reciprocity is getting better but not quickly)
So it's that sense that they have to scratch and claw to get the title where we can just sort of make it up that bugs them.
I think we should switch to a different title scheme. I'm going to be a Doctor of Site Reliability (you know since I'm already doing operations....)
Personally, I never call myself an engineer. Partly for the reason it annoys engineers, but partly because I don't think of what I do as engineering in the first place. And I think the reason for that is I have studied the hell out of CS, programming, and math; but I have not studied a lick of engineering! Learning a few engineering approaches by needing to stress-test software, because it's too complicated to grok, does not qualify one as an engineer in my mind.
I do however wish that people were better able to make the distinction between titling oneself 'software architect' and claiming to be a sub-type of architect. Perhaps it's too subtle. What I mean is, 'software engineer' and 'software architect' are singular roles, peculiar to this industry, that happen to be made of two words.
Software engineering has been recognized as a discipline of professional engineering since 2009 by NCEES, the national body of engineering licensing boards in the US.
That isn't what I meant. More like programming is math (somewhat closer to its own field of mathematics) but it isn't usually engineering, though sometimes it is in a more abstract sense.
I'm also fine with 'software developer' especially as we've largely moved away from programming computers, and at best most of us are programming abstract machines that bear decreasing resemblance to computers.
Consider a fuel injection system from the 1960's. It was a mechanical computer. Was that not engineering? It was certainly designed by a team of engineers.
These days, it's software that does the same thing. Why is that not engineering?
The material aspect is engineering. Is the logic engineering? Do you engineer logic? Would a mathematician think of contriving logic as engineering?
In order to discuss categories at all, you have to place some limit on how far to stretch the equivalence of different things. Sure, a physical thing is transformable to a logical thing, but doesn't that affect our categories? We're pretty bad at finding or agreeing on the lines between the categories we create, so I don't worry about that much.
I didn't say that programming is never anything like engineering. I apply engineering-inspired approaches to my work all the time. But here's another perhaps eccentric opinion: when I'm thinking like an engineer, it's usually to compensate for the code being too complicated to read. I consider that a pragmatic response to a worrying failure, not something to aspire to more of.
> A big part of software engineering is to engineer the logic to get the correct result as fast as possible.*
Engineering is all about working within a set of constraints. Things that are easier and/or cheaper to manufacture, have clearly been engineered that way.
It can't be a coincidence that we consider CPU time and memory footprint "costs".
We consider them costs because they are. If you can execute code on your server farm 1% faster, you can save millions of dollars in server costs. Hence software engineers who work on server farm code tend to get paid very well.
Replying here because I'm becoming enraged by HN rate-limiting our perfectly civil discussion.
I definitely see where you are coming from re: 'engineering' logic. As I said before, I don't have a huge argument against this. However, for me this is where the metaphor blurs into near-meaninglessness for me. Optimization happens to be a specialization of mine, and I can't find a reason to think of it as engineering, except for the fact that I take measurements. The optimization itself is more like applied information theory. I can agree that the measurement + iteration is perhaps engineering.
For the record, I don't consider a programmer who connects up various packages designed by others as much of an engineer. A programmer who designs and codes the load managing software for an electric utility is certainly doing engineering. There's a line between the two, but it's definitely a fuzzy line.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'
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.
> 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."
The first rate engineers I've known were competent mechanics as well. A traditional engineering course of study involves lots of time in the shop.
A mechanic becomes an engineer when he goes beyond merely implementing "book" solutions - when he starts understanding the "book" solutions, why they work, and where they come from.
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.
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.
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.
> 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.
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?
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.
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.
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.
>Since regulation of the practice of engineering is performed by the individual states in the United States, areas of engineering involved in interstate commerce are essentially unregulated. These areas include much of mechanical, aerospace, and chemical engineering—and may be specifically exempted from regulation under an "industrial exemption." An industrial exemption covers engineers who design products such as automobiles that are sold (or have the potential to be sold) outside the state where they are produced, as well as the equipment used to produce the product.
According to the other:
>Engineering licensure constitutes an integral part of the program of professional development of many companies; so much so, in fact, that many progressive companies have specific policies encouraging licensure and providing concrete assistance to engineers taking their first steps toward licensure
This implies that they are engineers even before licensure.
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'.
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.
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).
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:
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:
"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.
> “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.
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
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."
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.
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.
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.
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.
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?
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.
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
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?
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?
