Besides, yes, of course, the civil engineer, what if bridges fall, certifications, professional order, etc. What about the electrical engineer making a portable radio, or a cable? We were just talking about how those can be just as bad as software (https://news.ycombinator.com/item?id=10508494).

In contrast, the doctor has certifications, a professional order, etc. So does the lawyer. Are those engineers? No. Turns out those things have nothing to do with the concept of engineering itself, but rather with the kind of legal framework that is appropriate in some businesses that carry a high risk of personal damage to others, and/or with the desire and ability of certain groups to control access to a profession. All of which are tradeoffs, which means there needs not be a single set-point that is ideal across all fields of engineering. As any engineer could have told you.

That is the entire point. A Professional Engineer is the equivalent of a board certified medical doctor, or a lawyer admitted to the Bar in a particular state. In Ohio, a Professional Engineer is defined as http://www.peps.ohio.gov/4733/473301.aspx Restrictions are outlined at http://www.peps.ohio.gov/4733/4733021.aspx Note the exception for train engineers. You can use the term engineer as long as you don't confuse anybody into thinking you are a real engineer, i.e. sanitation. I like to call myself the Doctor of Love, but no one is going to think I'm claiming to be a real medical doctor.

There are legal consequences for claiming that you are an engineer when you are not. Check out the 2014 consequences in Ohio at http://www.peps.ohio.gov/NewsReleases/2014.aspx You get your name in print and in public for being incompetent and unethical. It is similar in all the other states.

The disciplines that can become Professional Engineers are listed on the right hand column here http://www.peps.ohio.gov/Exams/ExamDates%7CDisciplines.aspx Unfortunately, software engineering didn't make the list, although, electrical and computer did. I can think of circumstances where you would want software engineers to make the list. This is probably the result of corporate influence. PEs are more expensive. And a blanket Certificate of Authorization (CA) is cheaper. If you are an engineer via a company CA, you are only an engineer while working at that company.

You might claim that this is just rent seeking similar to a barber certificate. Yet, not many people die or have their lives ruined by barbers. You might get lice though.

It is interesting that you can no longer become a PE with a 4 year degree anymore that I am aware of. You used to be able to, although your apprenticeship was considerably longer.

Software engineering, in contrast, is rushed out the door by typically over-worked, junior, and small teams. Blame the management, not the engineers.

But more importantly, this is totally beside the point, because the two problems aren't even the same: most software has to change constantly; structures mostly stay the same. The hard part about software engineering is designing for flexibility -- it's ridiculously easy to build software that never changes.

Oh, and by the way, it is extremely common to have significant structural flaws in major construction projects; they simply find ways to go in and fix them before the building collapses, but not always before leaks occur, mold grows, etc.

The broad brush is especially problematic. If "programmers" should stop calling themselves "engineers" because of the prevalence of poor quality software, couldn't one argue (equally speciously) that "writers" should stop calling themselves "journalists" because of the prevalence of things like listicles and clickbait? In journalism as well as software, the garbage seems to far outweigh the good stuff (by volume). And in both fields, some professionals are trained, but many are self-taught, and neither skills nor ethics are uniformly incorporated into all practitioners' work.

I believe there _is_ a legitimate issue around the quality of software. But I don't see how demoting the class of people who build software brings us any closer to improving that situation. Rather, I'd be interested to read a thoughtful article about _why_ low-quality software remains prevalent. (I have a feeling it's because bad software remains economically viable -- in turn because it's still actually useful to people. A bridge that falls down is useless. An app that crashes every day is very frustrating, but potentially still worth the price. I'm just guessing, of course, but that's why I'd love to see a well-researched article that seeks to understand the problem before prescribing a solution.)

I think the author simply has no idea what either field entails, and has proved me now to denigrate the worth of an English major's career.

Seriously though, there are so many kinds of engineering: Structural engineer Geotechnical engineer Chemical engineer Biomedical engineer Genetic engineer Mechanical engineer

Just to name a handful. Software engineer clearly fits.

Software engineer is one of those titles taken by programmers for prestige. There are no calculations involved. There is just sweat. It is like calling CAD drafter, a CAD engineer for all of those times he sweats away on enormous drawings.

Engineer is a high ranking title, that bears command and direction, not a role done by programmers who listen to a manager grunt.

Unless you're a junior developer you should be able to do more than just grunt work. If you think grunt work is all there is to software development, you frankly don't know what you're talking about.

I've worked with software developers in tech companies that plan and fine-tune code and data formats based on metrics like memory use and performance -- exactly the calculations you claim aren't involved in software.

The difference between software and physical objects is that the resource cost of producing software is zero so the difference between implementation and simulation is often non-existent. So unlike physical engineering where you necessarily need to run calculations because testing is expensive, you have a tight feedback loop that allows you to tweak a system under test in ways physical engineers could only dream of -- and even so, better simulation tools are already saving physical engineers a lot of number crunching.

> Engineer is a high ranking title

In your opinion. You already stated crane operators are called "engineers" too. That's the standard you need to compare "software engineers" to. Is software development more like engineering than operating a crane or less?

> done by programmers who listen to a manager grunt.

No true Scotsman, much? You're not seriously claiming engineers are never constrained by decisions from superiors, are you? The only difference I can see is that (like lawyers and accountants) engineers have skin in the game that disincentives following certain orders -- exactly what has been asked of software developers in the fallout of the VW scandal.

There has never, ever, ever, been a programmer who has been barred from programming for selling shitty code. There have absolutely been engineers barred from engineering for selling shitty designs.

The only way to make this (frankly uninteresting) argument end is to either hold programmers accountable for quality, or stop holding engineers accountable for quality. Until then, you're using one word to refer to two groups of people with wildly different work requirements, and there will always be people complaining about that.

Full disclosure: I have done both kinds of engineering for a living.

What about an 'engineer' (a person who designs components for a large corporation for money)? How are they a different bunch than a 'software engineer'?

> There has never, ever, ever, been a programmer who has been barred from programming for selling shitty code. There have absolutely been engineers barred from engineering for selling shitty designs.

There have been engineers who have had their licenses permanently revoked, but nobody has ever been "barred from engineering". Those are not the same thing (though I doubt a company is likely to hire an engineer who is so bad as to get their license revoked).

> The only way to make this (frankly uninteresting) argument end is to either hold programmers accountable for quality, or stop holding engineers accountable for quality. Until then, you're using one word to refer to two groups of people with wildly different work requirements, and there will always be people complaining about that.

The way I think it should end is for software engineering to be separated from computer science at the university level. ABET-accredited BSCS programs are practically that already, but most CS programs don't give a crap about ABET. So, scrap the BSCS and replace it with a full-ABET BSSwE and let the people with academic interest in CS get a BACS. As for non-degreed programmers, other engineering fields already have established practices for advancing a non-degreed technician to full engineer and those can be adapted to this field.

I can't answer this question, because "components" is too vague a word. You could be talking about software components, or mechanical components, or financial instruments... sorry, I just don't know what you're getting at here.

> There have been engineers who have had their licenses permanently revoked, but nobody has ever been "barred from engineering". Those are not the same thing (though I doubt a company is likely to hire an engineer who is so bad as to get their license revoked).

An unlicensed engineer is not allowed to identify as the engineer-of-record for contractual purposes; that is, they can no longer 'stamp the drawings.' Sure, a company could hire a defrocked ex-PE to do the work, but they would still need an active PE to sign off on the work ('stamp the drawings'). So while obviously nobody is physically restraining them from installing AutoCAD, they are not able to meet (common) contractual requirements in engineering work.

> The way I think it should end is for software engineering to be separated from computer science at the university level.

I completely agree with your assessment, except that I don't see CS as being B. A. material, since it's basically applied mathematics, which has traditionally been B. Sc. territory.

I meant literal electronic and mechanical components.

> An unlicensed engineer is not allowed to identify as the engineer-of-record for contractual purposes; that is, they can no longer 'stamp the drawings.'

Correct. However, firms operating under a Certificate of Authority do not require a specific engineer to 'stamp the drawings'; the firm itself can do so. This is common with respect to mass-produced consumer goods and things of that general nature. None of the engineers who actually did the work need to be licensed, but they are still engineers. The CA thing may be unique to the US, though.

> I completely agree with your assessment, except that I don't see CS as being B. A. material, since it's basically applied mathematics, which has traditionally been B. Sc. territory.

I was getting confused by the BA in Physics. You are right, in that the BS in Physics is what you take if you want to "do physics", so a BSCS would still be appropriate for those who want to "do computer science".

The deeper problem is that most of the industry doesn't seem to care about degrees, much less ABET accrediting. I have two ABET accredited degrees (BSc, MEng), but that doesn't seem to matter in the slightest to a large number of the companies that I've applied to/interviewed with.

The bootstrapping problem here is that accredited degrees and licensure don't matter until companies say they matter and companies won't feel they matter until other companies decide to start requiring them.

In my current job I've started to see first hand a bit more that I previously saw as to how accreditation and licensure matter to other engineering fields and what that means, and it is eye opening to compare to software right now.

I'm not at all sure the existence of engineering societies and licensing is the litmus test. That they exist is undeniable. But that also varies state by state. And not all fields have anything like uniform standards.

Software Engineer fits very nicely into this ecosystem.

I don't get the feeling that there practices and processes that everyone writing software agrees are the absolute right way to do things. It seems more akin to a craft than to an industrialized application of basic science, like a bridge or ship.

What is the equivalent of Newton's Laws, for software? What is the equivalant of logarithmic tables and books of standardized information on materials? What are the equivalent of standard alloys and formulations of concrete?

I think that programmers and software companies will eventually be held accountable for quality. But first, there needs to be some strong consensus around how to measure and test for software quality. That might take a while.

Circuit topologies are like design patterns. Lists of components are like package repositories. Datasheets are API documentation - both are fields where the majority of details you have to deal with were decided by someone else.

It's interesting, when viewed through the lens of this discussion, EE seems like an early form of software - using specific materials for their ability to stay out of the way, seeking components that are a mathematical ideal, extremely reconfigurable, complexity is the enemy. Which isn't surprising - it's not like people were blind to the advantages of abstraction before computing.

Perhaps EE was the horse running out the barn door with the term "Engineer", but he's long gone now.

(Mechanical Engineering is in a similar position - there are many people that you would call engineers, but they're not PEs nor responsible to one. Safety is achieved by product regulation and testing, rather than a trusted creation process)

My understanding is that electrical engineers come out of school, and often go right to work professionally. Whereas graduates of computer science or software engineering college programs sort of famously are usually bad at building "real software" until they've served an apprenticeship of some kind.

I mean, a datasheet describes a physical thing that doesn't change, right? If you install a hardware circuit, it's going to work the same way until entropy takes its toll. Whereas APIs and packages are far more complex, and change constantly.

I agree that EE is the obvious precursor to software, but I think they are very different today. Companies that were great at EE--like HP, Sony, Phillips, Toyota--have struggled with software.

Electrical engineering at least has a few hundreds years of electricity physics experiments and theory behind it. If we think of the basic science of software, I think of computer science or information theory. Neither is much over 70 years old at this point.

There are basic quantities (current, voltage, time), and every component has an associated formula that model how they behave. But software is similar in that every instruction (eg opcode, function, or program statement) has equivalent well-defined behavior.

> electrical engineers ... often go right to work professionally

Sure, but they still start off slowly and work under someone more senior. They certainly don't come out of school with an understanding of what circuit topologies are practically used or a great intuition of which factors actually decide designs.

> Whereas APIs and packages ... change constantly

Only if you constantly change them out! Chips have revisions too. All of these differences strike me as being about scale of complexity, rather than full on new phenomenon. And it's true, for electrical engineering complexity is bounded by cost, even though there can still be a lot of complexity in a cheap chip (but the manufacturer is incentivized to get this exactly right, too). Whereas with software we're often burning GHz chips to perform the same function that 5MHz micros handled just fine.

So I think the root of the disagreement is whether you approach it "from the top" or "from the bottom". My above argument is coming from the bottom - EE battles a lot of similar facets as software, just a lot less complex.

If you take software engineering as being fundamentally about managing complexity (and therefore imply that it couldn't really get started until we had horsepower to waste), then I'd call that viewpoint "from the top" in a sense. Which is probably more appropriate, especially as complexity grows and grows.

But that doesn't mean that the "bottom" "fundamentalist" viewpoint is useless, either. It's not that engineering principles are inapplicable to software, but that they are ignored as a result of the environment the discipline finds itself in. One way to change that environment to encourage more rigor is to change the culture of the field, which IMHO can be helped by calling it "Engineering" and pushing it more towards so, rather than modeling the culture around eg flaky webcrapps.

It makes me think of the various disciplines within science. In theory they are a single stack--chemistry can't violate quantum mechanics, because chemical interactions are just very complex quantum mechanical interactions. But they're so complex that the mathematical tools of quantum mechanics can't be practically used for chemistry (beyond super simple reactions). For humans to analyze and manage chemical reactions, we had to invent a new set of analytical tools that are specific to the level of abstraction that we call chemistry.

And again, on top of that goes biology, which is after all just very complex chemical reactions. But we don't use chemistry equations (or quantum mechanical equations) to analyze genetic disorders.

Maybe software is sort of akin to biology. It's just super complex circuit design, which is itself complex applications of basic electromagnetic theory. On the way "up from the bottom," each time the complexity gets to be too much, we have to invent new mental tools to manage the system at a new level of abstraction.

Are the mental tools for software as robust as they are for circuit design? I think about the implications of security when it comes to APIs and packages. I might not want to update my package, but what if a major vulnerability is disclosed and patched? Now I have to update it, and because security and features are often pushed to the same production branch, I might get breaking changes with the patch. I know not every API and package does this, but it seems like many do. Old release versions are only supported for so long, typically. And depending on the patch, it might not even be possible to maintain complete compatibility with old APIs.

I agree with you that the key is culture. I've felt a significant shift in managing websites over the past year due to security. Instead of days to apply open source community patches, I only have hours, or maybe minutes. The default is shifting from "test security patches before deployment" to "deploy security patches instantly then see what we need to fix," because it's harder to recover from a hack than to adapt to documented breaking changes.

I think the implications of security are only just now beginning to percolate into popular consciousness, which will create demand for higher standards with software "engineering." Look at the recent car hacking stories, or the Ars Technica coverage of IoT security, which got picked up by NPR among others.

Thanks for good discussion.

Liability for damages seems a start, though as I have said repeatedly I think it should rest first with whoever deployed the software in question.

This is patently false. Engineer is a title that can be applied to a person in countless types of engineering. Your statement simply cannot be true as it's not even feasible to bar someone from all types of engineering.

> Until then, you're using one word to refer to two groups of people with wildly different work requirements, and there will always be people complaining about that.

No it's the same word. There are people who engineer physical things that do not require certifications, governing bodies, etc.

You're drawing a very, very dotted line saying one side is an engineer and the other is not which is just arbitrary.

But degrees and responsibilities are often closely related.

http://www.fastcompany.com/28121/they-write-right-stuff [1996]

"This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved."

"The most important things the shuttle group does — carefully planning the software in advance, writing no code until the design is complete, making no changes without supporting blueprints, keeping a completely accurate record of the code — are not expensive. The process isn't even rocket science. Its standard practice in almost every engineering discipline except software engineering."

> The title “engineer” is cheapened by the tech industry.

A lot of 'cheap' techies are making way more money than officiated engineers

By PE I mean: http://www.nspe.org/resources/licensure/what-pe

(from google) Infrastructure : the basic physical and organizational structures and facilities (e.g., buildings, roads, and power supplies) needed for the operation of a society or enterprise.

In some countries, Facebook is viewed as "the internet" and the rest of us consider it to be just another social network (albeit one of the biggest) - and for all accounts, the internet is just as important if not more important then some utilities - a company can survive without water (technically) - some companies now a days can't survive without an internet connection - their 100% internet based.

Therefore - I'm an engineer - I build buildings (websites) that allow people to do things - be it educational or informational or to sell stuff.

... i completely understand the argument being made but it can be made across the board - Is a parent that home schools their kids a teacher? Is an employee at McDonalds a chef? Is a PHD a doctor? All titles have different meanings when used in different context.

</getoffmylawn>

Other than that I agree.

These restrictions have more to do with the history of these professions than with their intrinsic qualities. In Europe a lot of them can be traced back to the late middle ages -- and in North America they can generally be traced back to Europe.

I agree that these terms may have legal implications in some jurisdictions, but that's irrelevant to the discussion of whether they are accurate.

However, I see quality output as a false dichotomy (rather, negative correlation) with bureaucracy / regulation of an industry's workers - look at the horrendous crap being produced for the Pentagon. Forget the glitzy articles in Wired and Techcrunch for defense-tech companies - most tech for government is done by under-qualified folks trying to make a quick buck off of Uncle Sam that couldn't really make it in the commercial software world. They'd be hard-pressed to make anything even close to some Chinese knock-off of a tech product if it came down to the wire. But I suppose this is because most defense contracts are regulated based around political and social requirements (see: the advantages for being a disadvantaged minority in getting a defense contract, plus Veteran's preferences) rather than actual functional requirements. Maybe the medical software industry is a better example of regulations in the right place (not that it's well done).

The distinction is pretty difficult to make. Where does electrical engineering cross into computer engineering, then into software development? If your program runs on a FPGA, is that engineering or software development? If you program mathematical models for controlling boosters for satellites, engineering or software?

Is the distinction the person writing the software? A ChemE writes a program to control the dispensing of certain chemicals to maintain a reaction is engineering, but if a guy without a degree does the same, it's not?

Like it or not, software is a major component to engineering. We have progressed to the point where lots of products cannot be made without some level of computing.

The argument that "simple" software is somehow not engineering is also bunk. Mech.Es design mundane shit all the time. Somebody makes money designing door handles and light switches. Just like people make money building apps.

However thats just a title an official title and I don't care so much about that, since that says nothing about how much you could do. since mostly the newer generation with these titles knowing less and less. Btw. I also don't like people who care too much about it, they are mostly the 'bad' ones out there. if somebody would call me an engineer, fine. however I would never call myself so.

Seriously though, Software Engineers will maintain the status of engineers whether they like it or not. And that's because it is real engineering work. Licensed or not that doesn't matter one bit.

If there are Software Architects they are very senior and experienced and hired into a position that asked for a Software Architect. They design entire systems not just a page here or there.

The reason they call themselves software architects is that they're mostly working on software architecture. Granted, the title is overused because scantly few companies have the scale at which it makes sense having a dedicated person for that but I've seen plenty of "art directors" prettying up PowerPoint slides, too.

The problem isn't that there is no such thing as "software architecture", the problem is that it's usually not useful to extract it into a separate role (although that doesn't stop people from trying), making the title more ceremonial than descriptive.

They're not developers, so what is the appropriate term you would apply to them?

Architecht is crossbreed between civil engineer and an artist. "Software architecht" should logically be front end designer/manager.

"Software designer" sounds like it belongs with "web designer" and "print designer". "Software architect" and "software engineer" won't confuse anyone looking for an actual architect or any of the other various flavours of engineers.

The author mentioned multiple times that civil engineers build bridges. Cool. Bridges are static. Updating a bridge is logistically difficult. You need expensive, heavy machinery. You have to redirect traffic. There are huge safety concerns for anyone standing below the bridge. Some of these things ring true for software engineering too. Voyager I has travelled almost 20,000,000,000 (thats 20 billion) km since it left earth[1]. Hong Kong's subway system transports over 5,000,000 (5 million) people every day and boasts a 99% on-time rating [2]. Google's autonomous cars have driven themselves over 1,250,000 miles since 2009 [3]. What do Voyager, Hong Kong's subway, and Google's cars have in common? They are all powered by software.

I don't dispute that quality is one of the first things to go at most startups, but to say that software engineers aren't "real" engineers because we have different goals and constraints is absurd. PEs (professional engineers) are generally concerned with quality, safety, and efficiency above all. This makes sense because trains, planes, and automobiles can't easily be fixed if something goes wrong. Remember the Toyota fiasco in 2009/2010 when the cars' gas pedals were getting stuck? The driver couldn't stop the car and this resulted in at least 10 deaths and a settlement of $1.1bn [4]. That settlement doesn't include the ~$3bn that Toyota spent in recalls, probes, and redesigning the gas pedal[4]. These are not issues that most startups face. We optimize for fast feedback loops that give us reliable data which we can use to improve the experience of using our product. In many cases, quality is sacrificed in favor of speed-of-development. Is it perfect? No. Is this engineering in the traditional sense? No. Does that mean we aren't engineers? I don't think so.

Building a rocket is difficult from a technical perspective. However, I believe that, in some ways, building a web application is even more difficult. Rockets are not concerned with human behavior. The few humans who will be interacting with the rocket are highly technical and have been through months or years of preparation. That's not the case in the work that I do. On the web, you must account for the knowledge and experiences of every individual using your product. The goal is to come up with solutions that anyone can intuitively understand without explanation, regardless of whether they've been using computers their entire life or if this is their first time. This is inherently a ridiculously difficult problem to solve because of human nature. Accomplishing this goal requires building complex systems that can handle interaction from thousands or hundreds of thousands or millions of individual people, each with their own unique perspective on life and technology. Moreover, there are a number of highly complicated back end systems for things such as automatically scaling infrastructure to meet demand, pipelines for collecting and analyzing logs and data, and storing and retrieving data in an efficient way (in some cases, sub-millisecond analysis over billions of rows).

My point is that this article seems to have been written by an elitist person who does not understand the work of the people they are condescending to. I agree that, in general, software should be of higher quality, but compared to mechanical, electrical, and civil engineering, software is still very young. We are learning the ways of traditional engineering, forging a new path towards reducing time-to-market for new products, and inventing and building for a relatively new platform (the web) at the same time. There will be bumps in the road. That does not take away from the fact that software engineers solve difficult technical problems, which I believe is the essence of engineering.

[1]: https://en.wikipedia.org/wiki/Voyager_1

[2]: http://www.cnn.com/2015/03/29/travel/hong-kong-mtr-success-s...

[3]: http://techcrunch.com/2015/11/02/google-self-driving-car-upd...

[4]: http://www.wsj.com/articles/SB100014241278873246691045782034...

I do think we programmers in general deserve more respect from society at large for what we do, but pretending to be something we are not (engineers) doesn't help our case.

Job titles are a cultural thing and mostly cosmetic. Most engineers don't do much engineering in their actual job.