[pixl97]

>A bigger problem for me personally is the high cost of reducing developer productivity and increasing operational risk just for the sake of cyberponies trying to defend their job.

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"

[Nursie]

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

[Kamq]

> I have my doubts about being a serious engineering profession.

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.

[flakeoil]

I don't think the standards have to be low, but the software engineering field would have to be narrowed down. Only teach and use a certain few languages, only use certain tools, only use certain patterns, only use a specific few frameworks etc. That's basically what construction engineering is. There are many ways to build a house, but only a few that are approved and accepted.

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.

[Kamq]

> I don't think the standards have to be low

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.

[exclusiv]

> This is why programmers are not licensed engineers, and I have my doubts about being a serious engineering 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.

[almostnormal]

Bridges don't usually fail because some worker layered some reinforcement wrong before covering it in concrete, but by issues on the engineering side.

Some software issues are caused by engineering, but most of them are just some implementation detail like an "!" in the wrong place.

[exclusiv]

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

[cdchn]

Lower stakes having looser tolerances is an engineering trade-off.

[xmprt]

I think programmers should re-evaluate the stakes that they're playing with. Even seemingly inconsequential things can have pretty large impacts at the scale that programmers operate. For example, if a form that you write doesn't properly support unicode characters then you might have just locked out millions of people from non western countries from using your software.

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.

[noirbot]

But isn't that part of the poor comparison with other sorts of engineering? If I build a bridge or design a machine, I have a pretty good idea of who will use it and for what, and it's engineered for those use cases, and some reasonable edge cases. Plenty of medical and chemical engineering isn't tested on anything close to the breadth of humanity that could be harmed or excluded from using it.

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.

[mlinhares]

Did you mean english speaking countries? Because most European countries (that I would assume are part of the "West") require unicode support as names and last names include non-ASCII letters.

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

[noirbot]

You're somewhat right, though I was just parroting the parent comment's example. If anything, you're pointing out what a terrible example it is. If you drop unicode support, that's not "not thinking about your immediate users", it's shipping a pretty broken product in general in a way that's easily fixable in most projects, which transcends the "is it engineering" line by a good bit.

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.

[mlinhares]

You haven't seen them because they have already been burned by stupid systems that will not take non-ASCII characters so they don't even try, the most common Spanish/Portuguese first name is José but I doubt you'll find a José at your job.

[denton-scratch]

Mos european languages can be rendered without relying on Unicode. You use character-sets. 7-bit ASCII is a fossil from an ancient era.

Of course, if you need multiple languages on the same page, it gets more complicated, and Unicode makes sense.

[xmprt]

So wouldn't you agree that in a sense, the stakes for programming is much higher? Because you can have a global impact just by putting something on the internet, I think programmers should take more care into the work that they do and not less.

[noirbot]

Not at all. There's only a handful of bridges over the river near me that I could use to get to my friend's house. There's only one AC unit in my house that's keeping my house in a livable temperature. A failure in almost any "engineered" thing in my life would have more impact than the loss of literally any programmed thing in my life, and the only programmed things that come close are treated more like engineering projects in my experience.

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.

[interstice]

It’s high stakes in the sense that leveraged trading is high stakes. One person can provide value to a million customers, but it’s unrealistic to expect that person to be able to cover one million people’s worth of edge cases.

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?

[Kamq]

> So wouldn't you agree that in a sense, the stakes for programming is much higher?

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

[xmprt]

> A bad website will rarely kill someone

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

[pierat]

Counter: if you support Unicode, you also support homoglyph attacks.

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.

[Avamander]

Those stakes are often misjudged or simply ignored. Nobody cares if a thing takes 10000x more time than it could if it works, right? Boom, you just wrote Windows Update that wastes centuries of human time each day.

And we haven't even gotten to all the effort that is wasted due to insecure software, hacked devices and leaked data.

[alpaca128]

Software can have high stakes very quickly even if you don't expect it. Like that time hundreds of UK post office workers were fired (and worse) because higher-ups decided the faulty IT system was more trustworthy than hundreds of people. And that's still rather harmless compared to what's possible.

[mannykannot]

It is, but if you get it wrong, you can really screw things up. Not trying to get it right is not engineering, and just hoping you get it right is not trying.

[Attrecomet]

Software engineers shouldn't be, and shouldn't want to be, licensed engineers. Being licensed a pain in the ass, a huge bureaucracy (have fun learning about thousands of ISO standards for trivial stuff for your license) and stifles innovation. We accept certain jobs requiring bureaucratic oversight because the effects of too low standards are unacceptable to us, but repeat with me, "licensing is a necessary evil, not a good in itself". It's ridiculous to demand that every library author or writer of a corporate website be licensed.