This is an intellectually shallow dismissal and it frustrates me when I hear it made. The argument is most often used to diminish the status of software engineers; it has virtually no other truth value, but if we actually accept it, it does have consequences.
Planes don't stay in the sky, money didn't arrive in a bank account, technocratic administration of the government didn't continue another day, email didn't continue to hit inboxes, phones didn't continue to work, etc etc etc, just because amateurs got improbably lucky again today.
Our field has its challenges, but given the number of people who didn't die today because it succeeds the overwhelming majority of the time, it doesn't make sense to diminish the people addressing those challenges by deprofessionalizing them. Additionally, the practical impact of deprofessionalization would be "Software can't be trusted to the geeks. Let's give it to competent professionals, like the executive branch of the government. We have replete evidence they'll do a better job, mostly via writing requirements documents to give to Raytheon."
A quickly following second order effect of licensing engineers will be an extremely predictable one-two punch of a) differing career paths for licensed engineers and commodity code-monkeys and b) demographic differences in entrants into those two pools along axes that you will probably care about.
All it takes is one tick box requirement in federal contracting templates ("Vendor certifies that all engineers working on this system and subcomponents are duly licensed") to infect AppAmaGooBookSoft's HR policies. AppAmaGooBookSoft will institutionally love that requirement; people who care about the future composition of the industry's hiring pool should not.
We'll get to exchange being plausibly the most accessible white collar profession in the US for one which will be aggressively and formally policed at the point of entry by the same sort of folks who convince e.g. the ACM to advocate for immigration restrictions. Many folks are annoyed at the extent to which individual engineers engage in gatekeeping behavior. Few would consciously choose to advocate adding professional gatekeepers who have quarterly targets for gatekeeping productivity. That's not an incidental effect of a licensing regime. It is what licensing means.
I know you don't particularly like CATO, but CATO will win the argument about what will happen under a licensing regime by an overwhelming margin and, even taking into account you and CATO have very different values, you would hate the downstream impacts of that policy.
(This is perhaps a lot of effort for a lowbrow dismissal that was probably more intended to vent than be a policy proposal but this particular one is a 20 year hobbyhorse of mine. Our desired regulatory stance as a profession is not consequence-free; if we'd actually want a licensing regime, it should be because we've done the math and are willing to accept the consequences. If not, we should loudly and specifically reject the characterization that we're not equivalent to licensed professionals.)
I don't think you've actually responded to my argument, or any argument I would be likely to make. I am not in favor of licensure for software developers and feel like I've said as much on many occasions.
I'd like to give you a dozen paragraphs in response to your rebuttal, but unfortunately I don't need them to refute you. All I have to say is "none of this makes what we do engineering".
We are not engineers. We have none of the guardrails serious engineering has. We normally make decisions in an almost complete absence of consideration for safety, reliability, and security. Buildings erected millennia ago stand today, doing what buildings generally do, and even throughout the worst of the industrial disasters of the late 19th and early 20th centuries, buildings generally managed to keep themselves upright. Nobody suggests that civil and mechanical and structural engineering haven't progressed since then, didn't address vital safety problems, and didn't formalize their respective disciplines. They obviously did. But that's essentially the claim you're making about software. Just because planes don't routinely fall out of the sky doesn't mean we're not in the Triangle Shirtwaist era of software development
You can also overstate how much engineering generally is about rigorous processes and theoretical correctness as opposed to heuristics and empiricism.
I don't actually disagree with your general point. But there are plenty of examples of civil engineering project failures because of defective materials and the like and there are established practices in many areas of software.
I've worked in engineering outside of software--and was even on track to get a PE--and a lot of that was pretty ad hoc.
OTOH, Heartbleed had as much to do with critical open source code being maintained by someone who was basically doing on a shoestring via donations as a lack of software engineering processes in general.
It's not so much Heartbleed; I agree, that was kind of sui generis. It's just the more general sense in which our field has no guardrails to prevent people from opting for faster/cheaper time to market at the expense of security and reliability. Everyone in this industry is constantly drilling holes through the support beams and hanging whole new floors off them; the buildings collapse every week, and we just shrug.
I'm not even saying things must necessarily change. I'm just making the case that what we're doing isn't engineering.
Proposing, designing, building, maintaining, scaling, duplicating, etc complex systems that handle billions of dollars in commerce a year, billions of events a day, petabytes of data, etc.
Successfully doing that is a lot, lot more than being just a software "developer".
