Hacker News Reader

Comment by mmcgaha | Hacker News Reader

It has been many years since After The Gold Rush was published and we are no closer today than we were then. At some point software engineering will be a real profession but I doubt anyone will take action before some huge catastrophe pushes the issue.

View on HN

I don't like the idea of gatekeeping, it's hard enough to hire people.

In the US we don't really have licensing for engineers (there is PE, but it's not anything close to ubiquitous). I think it's one of the best parts of our engineering/tech culture.

You're an engineer based on the skills you employ to solve the problems you do, not because some body of people gave you a slip of paper that says you can employ those skills to solve those problems.

In the US, PE has made it so the word “engineer” is legally protected, like “doctor”. No one enforces it for software, so I wonder if it’s even enforceable anymore. But the law is there.

In some fields of engineering PE is pretty nonexistent. Some people come from other degrees (like math, physics) and call themselves engineer without difficulty. But engineering fields require a much more narrow and deep set of skills. generally the key classes to learn those skills come at the end of three or four years of prerequisite classes, so it's a pretty high barrier to starting without doing the degree.

In programming you can learn your way to advanced skills while getting paid. Once you know roughly one class worth of basics there's valuable contributions you can make, at least if you are decent at figuring things out on a computer.

Hate using this preface, but, unpopular opinion follows: The issue in the US is that the word engineer has been in common use to describe technical workers for a very long time. I've had friends who were:

* Engineers (and operated trains) * Manufacturing Engineers (who were really equipment techs) * Sanitary Engineers (who were really trash truck drivers) * UX Engineers (who were really web designers) * Software engineers (programmers) * Data Engineers (kind of dba-ish, maybe) * Culinary Engineer (restaurant kitchen designer)

Genericide has occurred. The boat sailed.

When the real estate industry wanted a word for "licensed seller of property" they had to make up a new word "Realtor" and protect that with a certification mark. The engineering industry really needs to do the same thing instead of harrassing the garbage truck driver, computer programmers and the guy who fixes the conveyor belt.

Not enforceable. Or at least entirely winnable in court. Such a victory happened recently in Oregon:

https://ij.org/press-release/oregon-engineer-wins-traffic-li...

TL;DR: such restrictions violate your freedom of speech.

This is heavily dependent on the field and state. PEs are quite rare outside civil engineering.

Gatekeeping in the software industry is a surefire way to slow down innovation. Software would stop eating the world, or only take a bite every couple of decades.

Sure because there is no innovation across the engineering fields.

The best of innovators have the same thing to offer regardless of formal credentials.

A big difference is whether or not this is well recognized, and by whom and/or at their own peril.

I think you are right and it's too bad. There are some fields that should have it.

For example, the software for self-driving cars should be signed off by a licensed engineer before it is allowed to go live. Many mechanical and electrical parts of the car have been designed by licensed professionals, why not the software?

One can verify and sign off on computations that approximate the physics or chemistry that will occur in a structure or machine, as a well established chain of procedures exist to go from crude formulaic approximations to micro or, if necessary, nano-scale simulations of electrical, mechanical, and chemical processes, and we know what to look for.

I don't think the same is true for software "engineering," as it seems that all possible forms of process can be subverted and cargo-culted, from agile methods down to code checking. Certainly there is room to remedy some shortcomings, but SWE definitely is the engineering discipline least based in physical fact.

The physics behind simulating the buckling of a structure is always the same, we can just choose more or less crude approximations of it, but SWE in general seems a lot more diverse. I can implement that simulation in assembly or some scripting language, and attach various bits and pieces to it to manage users and data; deploy it across the cloud if need be. But, there isn't a singular, time-invariant optimal path to achieving that, and what is true today may not be true tomorrow. One can work off basic principles, like the Agile Manifesto, but how can you quantify or even certify this shifting landscape?

Having studied both mechanical and software engineering at uni, I feel that you _can_ make the parallel between the two. It's just that in mechanical engineering we've converged a lot more over time. Out of convention and need for accountability much more than necessity. For example, for mechanical calculations we have converged on using mostly the same algebraic notation (never mind having minor differences here and there, such as in vector notation). Having an obscene amount of different notations, some so different that they are for the most part unintelligible to half the engineers out there, that would be unthinkable in ME, but is the norm in SE.

The _physics_ of a buckling structure may be always the same. But already the modelling techniques are far from obvious consensus: Do you do it analytically? Do you use FEM? BEM? Then there are a bunch of simulation techniques, i.e. for numerical integration, which you could use, much like you could use functional or imperative programming or OOP or whatever else.

So if we were to behave more like the _software_ branch of the engineering discipline in general, then we'd have a _much_ tighter space of languages that would be at all acceptable for any work deemed critical, like medical, administrative or aeronautical software.

I agree you can make software rigorous like in ME. The part which is hard is that debugging or proving properties about a program is much more difficult than writing the program. These costs are currently hard to amortize over multiple projects. Real-time systems have some of these facets (e.g., spacecraft).

For example, a memory allocator can be studied in the usual algorithmic sense or perhaps how they impact the stability of the system under randomized load. Can you prove the system remains stable? Yeah. Is it worth it when you can reboot machines and add some heuristics? No.

Currently, the big places which are getting any attention for verification of functionality are embedded applications and OS kernels. Even then, the depth of verification is limited to common bug categories.

> Many mechanical and electrical parts of the car have been designed by licensed professionals, why not the software?

Maybe some companies have some internal requirement for that, but generally speaking that's not true. Legal requirements for review and approval by a PE only apply to building drawings.

> At some point software engineering will be a real profession

I'm rooting for the same, finally we will earn like management /s

Reply on news.ycombinator.com