back

by calvinmorrison·6y ago·view on hn ↗
Fined for practicing engineering without a liocense. Institutions will always protect themselves but this is absurd
1 comments
Not really. I mean, fining this person was absurd. But licensing the title "engineer" isn't absurd; bad engineering gets people killed.
Bad engineering shouldn't be related to use of the general English word, nor should it be used as justification over ownership of such a word. I admit I am unfamiliar with this specific case, but if he claimed he was an "engineer as certified by X" I'd be more sympathetic to X claiming he's lying.
It's the same as saying you're a lawyer.
More like saying you're a teacher in this case. While using that title to get around regulations teaching others in certain settings could be a crime, use of the word colloquially while generally giving knowledge to others (especially if you were a teacher where you came from) should never be a crime.
In this case, yes. But more generally --- the context of the top comment on this subthread --- no.
In the US, if I say I'm a lawyer, I'm at least implying that I passed the bar in some state (although possibly not in your state). If I just went to law school or if I just read a few books on constitutional law, it wouldn't be normal to describe yourself as a lawyer and you wouldn't be legally allowed to represent yourself as one.

People who have even grad degrees in some branch of engineering and have been working in the field for decades. But simply have never had a reason to get a PE? Perfectly reasonable for them to describe themselves as engineers (but not, of course, as PEs).

> fining this person was absurd. But licensing the title "engineer" isn't absurd

You can't logically have one without the other. If he claimed to be an engineer (which he acknowledges) and the state claims the title for licensing (which it did) then you can't enforce that licensing without some sort of penalty.

Sure you can. You can make a legal requirement that somebody has to be licensed to sign off on things that require the license without fining for the use of the word. Imagine that you're an engineer in Germany, you go to Oregon and somebody asks you what you do for a living. You reply with "I'm an engineer" and get fined because you're not licensed in Oregon.
In an oddly mirrored version, up until about 12 years ago it was illegal for someone with a PhD from outside the EU to use the title "Dr." in Germany, without going through specific paperwork to get permission to use that title.

http://htor.inf.ethz.ch/blog/index.php/2008/11/06/you-can-al... quotes a Washington Post piece:

> At least seven U.S. citizens working as researchers in Germany have faced criminal probes in recent months for using the title “Dr.” on their business cards, Web sites and resumes. They all hold doctoral degrees from elite universities back home

A NZ PhD holder in Germany could get in legal trouble until at 2012 - http://www.stuff.co.nz/editors-picks/6783089/Germany-goes-fo... .

You easily can, by being more strict about what constitutes the use of the title of engineer.
Exactly: sign off on civil works plans: licensed. Charge for advice related to:: licensed. Everything else: not.
I really don't understand this backing of the state here.

There is a vast gulf between stating one is an engineer, which many people are, and that one is a PE.

Reminds me of zero tolerance rules at schools, where adults claim that they can't understand the difference between two very different things.

> I really don't understand this backing of the state here.

You're just letting your pet peeves color your perceptions. I'm not backing anything here, I'm pointing out that if you're licensing the title of engineer then it makes sense to protect that license and therefore penalise people claiming the title without being licensed.

> There is a vast gulf between stating one is an engineer […] and that one is a PE.

In Oregon, before this lawsuit, there was not.

> Reminds me of zero tolerance rules at schools, where adults claim that they can't understand the difference between two very different things.

Yes, your comment also reminds me of people refusing to understand basic concepts.

The simple point was that Oregon's position was foolish. You keep pointing to Oregon's position as if it makes any sense. When one sees a bad government policy used improperly you don't usually state "But the state says so, so I guess it's just the way it is".

It's a bad position and this case is an example of why it's a bad position.

You stated that "If he claimed to be an engineer (which he acknowledges) and the state claims the title for licensing (which it did) then you can't enforce that licensing without some sort of penalty."

Of course you can. He didn't build bridges for pay, which is the type of engineering the law is clearly about. He just stated that he was an "engineer".

But yes, I'm the simplistic thinker, for pointing out that shades of gray exist in your black and white definition of things.

What about software engineers?
The simplest way to resolve that dilemma is to acknowledge that almost nothing we do is "engineering".
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.

I'm still kind of haunted by this very concise and blunt argument by 'jcranmer:

https://news.ycombinator.com/item?id=22315607

(I hadn't read about the KC Hyatt disaster before).

The Hyatt accident was a pretty massive screwup. There are other examples. See, e.g. http://www.slate.com/blogs/the_eye/2014/04/17/the_citicorp_t...

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".

A proper train wreck requires an engineer.