This is why programmers are not licensed engineers, and I have my doubts about being a serious engineering profession.
"Oh, the bridge fell down and killed 15 people, but it was worth it because I built a lot of bridges this week"
Not everything non-software engineers do is life or death either, and there are plenty of software people who do work in critical areas that don't have that attitude. This oft-repeated view is a caricature.
Licensed engineers make all sorts of crappy consumer goods that fail all over the place. Conversely, there are software engineers involved in medical devices, defence and various other spheres that follow very risk-averse, formalised coding, verification and release procedures.
The fact that a lot of consumer-oriented software is insecure, flakey crap is a consequence of time pressure and risk tolerance, as well as nebulous or amorphous requirements. Should I release this now, and try to capture the market, move fast and break things, adapting functionality as I go, with quality important but not that important?
Or should I spec out a complete and formal design, maybe formally verify it, implement to that spec and thoroughly validate it all afterwards? There'll be no product for five years but that's OK.
This latter category does exist, but isn't especially visible because it's not very sexy, it doesn't have 'hero' engineers, and there are few techbros getting rich off it.
It's not. If it were, vaguely talented amateurs wouldn't run circles around people with degrees.
But to get it to that level, we'd have to figure out 1. how to teach it, and 2. how to measure it.
1 is probably more important, but you can't really have a licensed profession when the students being educated don't actually know how to do the job that you're licensing. You would have to set the standards so low that it would be a useless license.
It could maybe work, although new inventions would be slow to catch on. A bit like in construction engineering today.
Maybe for some security related tasks it should be a requirement in some cases. A bit like software for airplanes and trains etc.
Based on what you've described, I disagree. Most colleges have already winnowed things down to teaching in only one or two languages. Usually java and python. And from what I've observed, most students still don't learn much.
We, as a field, don't know how to teach people to code. The closest we've gotten is showing people what an if statement and a loop are, show them a couple examples, and then tell them to screw around for a while until it clicks. And for some of them it does.
If you want standards to be higher than a random teenager who screws around for a summer, this has to change. Or you have to accept that ~75% of college graduates are not going to be able to go into their profession.
You're conflating two different things.
Coding and programming does not make one an engineer. Just like assembling a bridge does not make one an engineer. Or building a house, an architect.
On the other hand, actual software engineering can be a serious engineering profession. As serious as any other engineering form.
Some software issues are caused by engineering, but most of them are just some implementation detail like an "!" in the wrong place.
Yes most of them (by the numbers) because software is more complicated than a bridge which has been a solved problem for a long time and because even the worker bees that write code have a more serious relationship with the software than someone pouring concrete in construction, which is also already a solved problem and for the most part - has one true way to do it, unlike software.
If you have proper quality control and budgets for that, then we'd have a lot less bugs that you are talking about. I don't get your point though.
You are saying software is so easy it's not real engineering and software fails because some coder screwed up? I don't buy that.
The success of every project comes down to quality engineering which encompasses a lot of things that are outside of just the part of the job called coding (budget, schedule, requirements gathering, build, quality control, risk mitigation, redundancy, ongoing monitoring, hosting/infrastructure, maintenance, etc).
A civil engineer is more of an engineer than a coder (which isn't an engineer) which is the conflation that caused my prior post.
However, a civil engineer is NOT more of an engineer than a real software engineer. I'd submit the opposite and the market agrees.
And if you don't believe that then you will eventually when there are more catastrophic failures in critical software. Probably AI or self driving cars when the stakes are higher. If it's a dumb bug as you allude to, that won't make it less of an engineering discipline. It would make it more.
I can't even believe there is debate about software engineering being a thing with all the incredible things that have been built.
And even worse, if you're building a "tiny low stakes" piece of a much larger software then you might end up accepting money from those paying customers who can no longer use your software because your form doesn't work for them. (I've had this happen to me personally). And then people don't bother fixing it because it's only 0.01% of the userbase.
There's plenty of "engineered" products that are designed in ways that don't support unicode or international electrical systems, or other factors that exclude "millions of people from non western countries", but they also just don't sell those products outside of western countries.
Just because I put something on the internet doesn't mean I'm thus required to support literally the entire planet's use of it, and I don't think that's "stakes". Sure, if your company has a Korean division and you forget to have Unicode support, that's a problem, but if you work for a regional company in Virginia, it doesn't seem like some failing of professional responsibility to not support Unicode in my forms.
Also, if you work for a "regional company" in Virginia and you don't support unicode you're likely excluding 11.5% of the Latino population that do make use of non-ASCII characters in their names and Asians, that are 7% of the population. So, yes, it is a serious professional failure to do that, even in "Virginia".
That said, I'd be curious what percentage of people with non-English names actually require Unicode for their names. Not every Asian or Latin person, or even most of them I know, use non-ASCII characters in their name, and very few businesses or applications require you to enter a full legal name that needs to be accurate the the language used to name you. I work at a company with a large amount of international employees and I'm not sure I've seen anyone with a non-ASCII character in their name, and I'm pretty sure Active Directory and Slack support Unicode. So while it would be a mistake to not have Unicode support, I am curious how much it would actually cause an issue. It would be inconsiderate to not support it on a form, but there's plenty of businesses who could probably operate just fine with only Latin characters.
Ironically, isn't part of the issue that most "engineered" keyboards in the US don't have any innate way to type those, and thus require your "programmed" OS or application to have the support needed to even type those characters with some chord of keys?
Of course, if you need multiple languages on the same page, it gets more complicated, and Unicode makes sense.
Regardless, none of that was the point I was making. You're claiming that because code could run anywhere, that it's therefore every programmer's responsibility to make it work everywhere, because that's "engineering". My point is that Engineering is nothing like that - most actual engineering is of a vastly more defined and constrained scope than most software. My mechanical engineering friends spend years building, say, an AC unit that only is ever sold to something as niche as hotels within a certain latitude range in North America.
Do engineers have to be more robust? Often yes. Should some software also be developed to that level of rigor? Yes. Should all or even most software be required or even expected to have that rigor? No.
So what’s better, keeping the ability for one person to have an outsized impact in improving others lives along with some caveat emptor, or bolting down the industry to the point that one line of code costs several hundred dollars?
That doesn't mean the stakes are higher. It means the potential upsides are higher.
The potential downsides are also much lower (a bad website will rarely kill someone).
The combination of these two incentivize bringing in as many people as possible, even if standards suffer because there's almost no downside (civilizationally speaking, companies do occasionally lose quite a bit of money).
That's probably true although I think eventually, that kind of callous line of thinking might actually get someone indirectly killed because programmers don't worry about the impact of their code.
A less severe (although in my opinion still live changing) problem is having an unusual name making it harder to book flights. Another example where having a NULL license plate got someone thousands of tickets [1]. Or IP addresses getting mapped to locations where they actually don't come from and now someone's house is getting searched because "their IP had illicit activity".
Coding probably won't kill someone but I still don't think it's low stakes.
[1] https://www.wired.com/story/null-license-plate-landed-one-ha...
https://www.irongeek.com/homoglyph-attack-generator.php
The real sad is that there's nearly no defense against this, other than scanning codepage of all text you see. At least punycode is available for domain names in URL bar if turned on.
And we haven't even gotten to all the effort that is wasted due to insecure software, hacked devices and leaked data.