No other profession trivialises their profession to the degree of software
ghuntley.com
ghuntley.com
First off, most people would disagree in the first place whether coding is a „craft“, a science or even an art. He‘s saying craft (which is taught by other craftsmen), but what he probably means with his certification is college/uni.
Now I‘ve seen some of the worst sins of coding ever done by CompSci „master crafters“, with PhDs producing the cherries on the cake, with Java classes having longer names than the 80 character line limit.
And I don‘t even mean the designed-by-engineers frontends with UX level „crime against humanity“ (hello, early Hadoop).
I mean actual backends where CompSci education should shine, but even very smart people don‘t grasp the inherent cumulated complexity of massive systems. Because creating complexity is what you learn at Uni, rarely removing it.
Log4J wasn‘t a bug. It wasn‘t a backdoor. It was working as specified.
Look, this stuff is hard, one way or the other. I don‘t think we need even more gatekeeping and cover-your-ass to keep out the smart people who fail at university because they challenge the status quo and an outdated curriculum.
You may talk about gatekeeping all day, but at the end of the day we do want the code in our pacemakers, cars and drones to be written by people following stringent standards, such that we have some idea of the quality.
The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.
This is the start of a bureaucracy that will grind progress to a halt. Because now instead of solving problems we get to create a commission who can appoint a club that have the right to appoint the master craftsmen who will be capable enough to formalize best practices.
If you think that's hyperbole on how this stuff works, it is not.
Furthermore, why would we assume people who enjoy debating best practices know actual master craftsmen?
> The fact that said standards may not yet exist is not an argument against that, it’s an argument against the status quo in standards.
The fact that said standards have been tried, and you don't know about them is a very strong argument against them.
This bureaucracy already exists, across myriads of RFCs, language design committees, FOSS groups, GitHub issues, Gitter servers, listservs. This process already exists, it just bumbles along inconsistently from community to community, company to company, project to project. And perhaps it should, because no size fits all. But it does exist and any attempt at formalizing them would not cause the start of a bureaucracy to exist, because such bureaucracies are in abundance in software development already.
The sense the OP is trying to argue for (rather unsuccessfully) is a government bureaucracy that forbids people from deviating from those best practices. This is "serious", you see, whereas a competitive market of ideas leading to the organic development of best practices (what we have now) is "trivial".
The problem with that idea is that although it pleases people who associate government control with seriousness, the evidence it actually leads to better outcomes is mixed at best, and negative at worst. Regulatory capture is a real problem in many industries, and the attempt to fix things with regulated "best practices" can often be short term hacks that also inconveniently render more robust long term fixes illegal (finance has a lot of problems like this).
In the software world you can look at things like MISRA-C or FIPS to get a taste of what everything would look like if we don't keep systematically pushing back against these misguided people.
"Software practitioners should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice software engineering."
The article very clearly argues for government control of who can be a programmer or not (who is doing the revoking, otherwise). That would be destructive, fatal to innovation and totally counterproductive.
Let‘s look at the results: NASA probably uses some of the most rigorous development and testing methods in the world, but I‘d still rather trust my life to the flight control software of SpaceX who doesn‘t give a damn about education.
The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?
My point is: I’m all for better code, but Culture trumps certification and standards every single time.
Why? Have there been any NASA manned accidents that were caused by software? There's certainly been big historical bloopers in the past involving unmanned probes, like getting metric and imperial mixed up, but doubtless NASA software quality is better now. And what is your basis that SpaceX doesn't care about education, while NASA does? Are you a hiring manager at either?
> The banks losing data mentioned by OP are way more rigid in their hiring and certification standards than a Stripe for example. Who would you rather trust on security?
Is that true that banks are more rigid in those standards? Or Stripe is more lax?
How did flight computer fail during Apollo 11 landing? If you mean guidance computer and famous 1201 and 1202 errors, those were not failures, but were caused by hardware bug they left unsolved on purpose.
Really? No, seriously, where will this end? Now we need better BEST practices?
I mean. This "best practices" wagon is just a nonsense. My impression is some people don't want the burden of thinking, so they want something to memorize. And blame when things go wrong - which they inevitably will, as in any and all "crafts" and "professions".
Engineering, medicine, etc, are all full of examples of failures. Is this evidence they should get rid of certifications and all bureaucracy? No.
Is software failures an evidence we should have more bureaucracy? No, it's evidence we need to think more and memorize less.
The average working programmer probably doesn't care whether their work is considered a science or not. Certainly I feel like the ROI on reading CS papers in my own career has been quite low. They have a habit of sounding useful and impactful until you finish reading them and realize there's a pretty major catch. I have a degree named "computer science" but it's questionable whether it was really scientific, given that science is usually defined as a study of the natural world. There's nothing natural about computer programming, outside of perhaps complexity theory. You could argue that maybe at the edges deep learning is blurring into a study of naturalistic phenomena, but you have to be careful, otherwise you reclassify pure maths as a science and I think everyone agrees that it's a separate thing.
(I personally hold that there are only three CS courses relevant to daily programmer life: graph theory, complexity analysis and state machines. Everything else is at best situational.)
Look at what's happened to medicine. Huge numbers of people have had their confidence in doctors seriously damaged over the past 2 years because they keep saying things that are patently nonsense, like "oh your period vanished for 5 months immediately after taking a vaccine, it must be a coincidence" (this happened to a friend of ours). Why do they say these things, well, because if they go against the party line on vaccine injuries they can lose their license:
https://trialsitenews.com/doctors-sanctioned-for-speaking-ou...
That sort of action has nothing to do with best practices and everything to do with power structures. The software equivalent would be something like, "if you imply Java is not the best language to build enterprise software in, you could lose your license" or "if you write forum software that doesn't run every post through this officially approved AI for misinformation, you can lose your license". It doesn't look like bugs magically disappearing. I'd expect the rate of bugs to go up, actually, as standards ossified and became irrelevant (see: FIPS).
Maybe the compromise isn’t to institute formal licensing, but rather pay more attention to and give more support to industry bodies such as the ACM/IEEE.
Of course best practices can only work for problems that have already been solved. There are plenty of problems that need innovative thinking and unorthodox practices. The more brain power you can dedicate to solving those problems, the better.
You can see the examples that were brought up here. Function name lengths, log4j, dealing complex systems. The first two definitely have nothing to do with CS, the last could be I guess, depending on the overall architecture, but lots of complex systems are just piles and piles of simple cruft. That's not a CS problem.
I don't think engineering is the right analogy here. A better one would be: Physicists exist, so do electrical engineers, and so do electricians. Physicists do discovery, electrical engineers do design, and electricians do implementation. And unsurprisingly, the electricians are the most likely of the three to require a license to do their work. Most programmers do implementation work.
Finally... No, I don't think a physicist would be a good engineer necessarily, particularly in this context. I mean, there exist branches of engineering that are more like physics -- yes, a physicist should be able to turn into an antennas guy, I guess. But I don't see why a physicist would be good at making designs out of digital building-blocks.
There's definitely a lot of ways that physicists and scientists in general don't make good engineers. But a physicist has a good shot at being a reasonable engineer, after getting over the fact that they don't actually know everything and rules of thumb and physical models have to be created taking into account the complex emergent behavior we see in reality.
Same thing for CS PhDs and software engineering. They should be set up to undertake these things well. Not being able to do so is a mark against them. They don't immediately understand the complex emergent behavior of modern computer systems but neither has any SWE.
We never get a chance to reflect critically on our product. Imagine if an architect always would have their first draft constructed, without consulting a structural engineer, or the municipality or even the clients. They can't because if they did their company would either run out of money while they are at the drafting table, or a different company will build another shoddy but functional building faster and outpace them.
This is how software gets made, not necessarily by unqualified engineers, after my degree and 15 years of professional experience I feel my first draft on a software project has a reasonable chance of standing up in the high winds. But hasty and incomplete processes.
Agile like processes are an improvement, at least there is allotted time for improvements and corrections while the apartment building is still 1 story before and the customer can at least walk around a fully furnished apartment before we slam the other 99 on top.
We never get the chance to have our code audited when it is done, but before it is pushed to production. Best we can do is have a test suite with good statement coverage.
That being said, if we improved this situation software would be only marginally better. As awful as some of these problems are, they can slumber in software for decades before causing any harm, and frankly the amount of harm is quite limited.
Much of the Internet is built on publically available code, so anyone absolutely has the chance to critically review those projects and products. It's not clear how more gatekeeping would be an improvement; in fact, it would most likely make things worse.
How many people could go "Hey boss, we're gonna take 2 developers and spend the next two sprints moving our code base away from the industry standard logging framework because it has too many features".
Sure:
- "Search for thing that do X"
- "npm install thing"
- "drinking cofee while it install 1000 deps"
- "it works"
- "end of critically thinking about this".
The "serious" qualifier makes this a "no true Scotsman".
If a developer thinks that, then one can always say "he is not a serious developer".
A few arguments you could search for, if you want to dig deeper:
- Licensing is used to restrict entry into the profession to prop up wages, i.e. it often turns into a form of wage cartel. In extreme cases it can degrade into a pure cartel without any connection to actual professional practice; NY taxi medallions are an example of this in which the license is tradable and rentable, because buying one costs millions of dollars.
- The qualifications requirements are often either redundant (everyone was asking for them anyway) or obsolete (the industry has changed but everyone still has to pass these tests). Obsolete licensing rules are often impossible to get rid of because the people who put effort into passing them don't want to see their "investment" be invalidated.
Again using taxi licensing as an example, black cab drivers in London have to literally memorize the street map of central London such that they can recite a set of street directions from any arbitrarily chosen A to B, on demand, from memory. It's called The Knowledge and there are examiners who test this. Just last week a newly qualified cabby was telling me about this. He recounted on how his first day he discovered that the Knowledge was useless for actual navigation because you can't memorize traffic conditions. So now he uses Google Maps/Waze anyway, because it lets you see congestion. The Knowledge became largely irrelevant with the arrival of high quality GPS units, but it lives on decades later because the licensing bodies won't remove a rule that gives them power and cabbies aren't allowed to deviate from it/like the way it keeps out low cost competition.
- Licensing can be abused for political purposes. The threat of medical license revocation is routinely deployed to silence criticism of government policies on COVID or COVID vaccines.
- Licensing is often subtractive rather than additive. The licensed software developer's answer to writing engine control code safely without bugs is MISRA-C. This takes C and tries to make it safe by writing down lots of rules to follow which get steadily more restrictive with time (MISRA-C:2012 contains 143 rules and 16 directives). The unlicensed software developer's answer to writing safe embedded code is Rust - the rules would say you have to use MISRA-C, so there'd be no point trying to go beyond it. Moreover nobody would have developed Rust because the internal drive for self improvement would be gone. The sort of people who created Rust are not the sort of people who also enjoy political lobbying, and the sort of people who funded it would have lost their motivation if they could just say "we comply with all relevant regulations" and wash their hands of errors.
An absence of ensured quality standards in the profession also doesn't mean that there is an absence of tests, these are moved to the individual company level instead, and, in our profession, often take weird turns like ritualized coding interviews.
On the point that no serious developer would think that this improves outcomes, I have to disappoint you, there are major companies like SAP with a culture of requiring masters degrees for almost all promotions.
But in practice, I don't think that works either. We're building immensely complex systems across numerous layers each of which is the result of thousands of engineering hours. The costs to properly harden and secure most systems is not worth it. And even if you spend the effort to harden the system, it could still fall to a carefully crafted attack.
If you get attacked by a 0-day exploit from a malicious nation-state there's a level at which most companies would fail.
Security isn't some binary thing, it's an onion. And there's no meaningful conversation to be had about security without first taking your risk profile into consideration.
Nothing would get done.
Nsfw ortho meme: https://images.app.goo.gl/fTKFFYP9vTgoFiAs6
Hiring a dev who's "Secure Developer Certified" might be an option too, but there would still need to be all the above checks in place to make sure they're writing decent code, so looking for the certification at the point of hiring is a bit redundant.
When you ask them how critical the things are they are doing, they like to (as you phrased it) think of themselves as skilled code surgeons who precisely cut away solutions to life or death problems.
When you suggest to them stricter rules, guarantuees, checks and laws like you have them in civil engineering or electrical engineering they look at you in horror: "What, you mean I can't just carelessly try out a new framework on a project?"
Programming to me is a multiplier profession. Unless you code for yourself privately, your code is going to impact other people, organisations and the environment we all live in. This can be a good thing because by making the right choice we can really shave off collective years of the useless stuff humanity does. But we can of course do the polar opposite as well: waste everybodies time, leak private medical data, create algorithms that feed violent racist content to kids, make mistakes that endanger whole industries etc.
Simple preventable things like uninitialized variables still caused the dirty pipe vulnerability in the Linux kernel in 2020. The only thing that tends to give me a little hope is the traction Rust seems to be getting — at least we can stop doing the totally obvious and preventable mistakes and move on to unpredictable and unpreventable ones?
The reason is simple - there isn't enough time in the day to both push out the required features and fix all the bugs. We prioritize features because that's what we believe increases our value. Whether or not that's actually true is a matter of opinion.
Our predecessors were expected to write code more slowly. They could take a year to make a small business app that a dev is expected to push out in 4 weeks now. And all credit to today's devs, we hit those deadlines. We achieve amazing things in very little time. But in our push to be as productive as possible we have largely forgotten that the most fundamental skill in software development - thinking about how to solve a problem well - hasn't changed at all.
We believe that using a new framework, or buying a faster computer, or typing on a different keyboard, will make us faster, more productive developers, and in our effort to compress the amount of time it takes to build something we have also compressed the amount of time we spend thinking about it. That's why we leave bugs in code.
A "small business app" would be far too expensive to build to "NASA" Standards, and furthermore, it would be wholly unnecessary to do so. Think opportunity cost.
I have worked in places where, basically, there was so much money pouring in that the drive to actually ship anything had all but disappeared. Thus the 'axis of perfection' took over: Build the perfect shining crystalline entity, no matter the cost. Rebuild your own tools, even where good, liberally licensed FOSS alternatives already exist. Etc.
I found the latter environments too frustrating to cope with, as I found "making code look nicer" did not lead to an existentially satisfying week.
This is why I both agree and disagree with the article. Because anyone can frankly build a house, and a lot of people around the world, not only do so themselves, they do so poorly. At the same time there are a lot of parts of software that are inaccessible to most software developers.
Banking and medical software developers tend to care quite a lot about your qualifications and even the modern coding interview is sort of there because our profession lack the “trade skill approval” seal that builders and electricians get.
On the flip side of this I live in the city of Aarhus. Some years ago we got a new form of public transportation called Letbanen, which is a street level metro (I’m not sure what they are called in English). It was sort of a standard product that my city bought and it runs in both Norway and Switzerland during their winters that are worse than hours. Last week it was cancelled 5 days out of 7 because the electricity lines were frozen. I love the thing and I don’t mean to complain about it or pretend to know why my city can’t make it work when a city in Norway can, but the fact is that it doesn’t work and tens of thousands of commuters haven’t been able to rely on it for a couple of winters now.
It’s CEO hasn’t changed.
This is a standard product that was build by certified people that keeps people from getting to their jobs without having a car (in Denmark it’s common not to need a car in our larger cities), and yet, there hasn’t been a lot of consequences for it failing the same way for several years.
As someone that's worked around banking and finance a fair amount in the last few years, I'd say this is not universally true. I've never worked in the medical sphere, but I have worked on everything from tiny payment systems at SMEs to massive compute systems at banks in the top handful of the fortune 500, to quasi-governmental inter-bank communications bodies, and really I've not seen any more focus on qualifications, nor reliance on 'hard' coding interviews than I've seen elsewhere in software.
Maybe medical is different, AFAICT finance and banking ain't.
I also think it depends on how you define quality. In terms of medical my qualification criteria is based around a 0 deaths or 0 failure rate over a lifetime, not so much what it was build with. Some people would likely disagree with that.
But for who gets in the door for implementation work, it's still tech conversations and a bit of "who you know" that count over qualifications and hard tests, in my experience.
But some banks (Starling in the UK) seemed to be able to work around that and have a decent CI/CD story, and as you say - it doesn't usually make the software any better, just adds bureaucracy.
The only people who I have met who turn the interview process into a gamut of algorithm puzzles, are people who happen to be very good at them. These also don't tend to be the people running things at banks, let alone large ones.
The problem with "artisanal developers" is that they tend to overestimate their proximity and underestimate how much of a "system" they actually should build. Most of the time they lack domain knowledge, too.
If you can identify the cross-cutting interactions that will result in the biggest risk for the project, and put how to handle those in a design that is communicated well, you can leave freedom how to do the rest and the craftsmen will be appeased. But that needs a good deal of domain (and people) knowlege.
A tram
I’ve read that they run so well in Norway because the goo they put on the power lines doesn’t get scraped off because they have two sets of rails, one for each direction.
It doesn’t bother me personally, I live inside the city so I typically walk or bike to work, so I haven’t followed the evolving scandal too much.
As soon as, say, a retailer or a bank can be sued to oblivion for bad and/or insecure software, whether it was written in-house or not, the regulations will flow back to the producers of the software.
We are still in the Wild West days. Enjoy it while it lasts. Once we, as a society, start requiring software to actually do what it says it does, the fun times are over…at least professionally. We will still be able to have hobby projects automating sprinklers and lightbulbs and such with the latest unlicensed (edit: un-warrantied, really) Raspberry Pi and Linux.
But at work we will be using buttoned down OSes, programming with buttoned down programming languages, using a (comparatively) small number of professionally licensed third-party libraries, and all this with some painful professionally certified software development methodology.
Edit: for clarity.
Buttoned-down OSs existed in the form of mainframes and minicomputers up to the 90s (I'm sure you know what happened to those). Government and corporate standardization often fails more than it succeeds (e.g. respectively, OSI and CORBA), and will eventually follow the trends of the commercial market anyways. Until governments start inventing their own operating systems with 60 years of code and multiple versions of multiple programming languages and standards to reimplement, I wouldn't be so worried.
Right now, state governments and federal agencies are panicking to find COBOL practitioners. That should tell you how even respectable stations can become ghost towns.
We don't need licensing and crazy security standards to build the 10000th SaaS app. It doesn't matter if it breaks or falls down or is built by a clown.
There are a few rare places where software actually needs to be very reliable, like say NASA or medical equipment or self-driving cars. Those places typically already have a very different culture and practices.
The trivialization of software comes from the VC/investor class imo. They want to desperately push this idea that everyone can code because it means a continuous supply of cheap labor. Pushing back on that idea is called "gatekeeping". Devs get mindfucked into devaluing themselves, and even if they realize this, they are competing in a pool of others who are similarly mindfucked.
I wish software devs would stop ceding power so easily. The typical arrangement is that you don't decide what to work on, don't decide how long it will take, don't have much say over the organizational structure etc. You don't have to passively accept shitty interviews, the obligation to make your code public, the complete decoupling of decision making from execution etc.
There’s absolutely no reason why software couldn’t have similar regulations and certifications for software sold to customers that carries liability.
I'd be against setting any sort of guideline currently. IT is still too immature and everything is still changing too fast. To make one easy example, setting guidelines for testing would just result in worthless unit tests.
I'd be more favorable to some FAA/EASA style of institution where we evaluate a company/project/people based on its incident-response track record. And even then, I still see too many recipes for abuse.
- certification is usually an expensive process which doesn't add value by itself - small teams are effectively removed from the talent pool due to the cost requirement, leaving only large (and less efficient) teams/orgs
You artificially reduce competition, to the point that the remaining entities are shielded by the initial barrier to entry and have very little incentive to do anything about it. You can keep raising the certification requirements: it's actually "good" for enterprises which can afford the costs, with basically little or no change in the quality of output.
This is not unique to software development either. I'm not against it by principle, but I'm very skeptical in how certification is applied in _many_ of the contexts I've seen it.
Would you agree that a teenager should be able to build a widget for a local business's web site for money? Or should a license be required to do that? Should that same teenager have to get a license to baby sit or mow lawns? Presumably you don't think of baby sitting or lawn mowing as professions, so that's the difference.
Maybe a license should be required to call themselves a "software engineer." But beyond that, I think this article views things in way too black and white terms.
I always view these pushes with a lot of suspicion given the nature of the people that tend to promote them.
Had this profession been a guild-like thing from the very beginning as the author of this article suggests then I think none of this would have happened.
If we took software engineering seriously overall we'd still have all the things where that's already the case. Compilers, machinery, infrastructure and so on. Sure we maybe would only have two delivery platforms that don't lose your data instead of 50 that do, but is that so bad?
For many years now every time people discuss raising standards in the industry there's always the line of argument that we lose a whole bunch stuff. To me it sounds like arguing that banning people from pouring lead into the river loses you a bunch of companies. Sure, but good riddance.
There are rigorous standards that will make your eyes bleed https://en.wikipedia.org/wiki/DO-178C and you won't have any fun with the latest frameworks and toys. It's designed to be boring and safe. The development process is excruciating. I remember from my short experience fun things like the person who writes the spec is not allowed to write the code and the person who writes the code is not allowed to write the test cases. Code coverage is not enough. You have to try to cover every combination of branching. https://en.wikipedia.org/wiki/Modified_condition/decision_co...
But in the end as the Boeing example shows. If you have people willing to subvert the regulations for their own personal profit then things will break.
Reality:
The code is written by the lowest bidder. This might be people with some form of formal qualifications, but also often is people who have no idea how a car is supposed to work, who do not even have a license to drive one. Imagine someone implementing a web app without ever having used a web browser.
The specifications are written by non-software engineers, and more often than not they contain a code-like description of the software, without any significant explanation. That's code written by people with no clue about software.
The tests may provide any coverage you can dream of, but they are unfit to detect any kind of bug. Which is obvious because the authors of the code and test have no idea about what problem the code is supposed to solve. And the only goal is to prove coverage not to find bugs.
In the end it only works because there is different people, who know how cars work, and test everything manually. At that point, coverage is of no concern at all, and bugs stay undetected, but the result might be just good enough. Also, it helps that (from a pure software point of view) most automotive software isn't exactly highly complicated.
If a Lunar Lander were to be on Mars, is only software to blame? /s
For me personally the lack of regulation is one of its best features of this profession. We already have to deal with enough corporate bullshit to add to it licensing and regulations.
I also think that good developers are able to be self-deprecating. Just because we muse over not working or writing bad code, we don't want to deliver a bad product or project -- usually the user doesn't see the code. So, I'm fine with being a bit less "professional", if my users are happy with my work product and it makes me seem more approachable and human.
This also holds for doctors.
There are a bunch of loosely connected elements here. The primary one, IMO, is the "anyone can be a dev" ethos.
A lot of this ethos is historical. Programming does not have long decades or centuries of history, like civil engineering, medicine or whatnot. In fact, programming was (relatively) recently something that users were expected to do. "Buy computer, program it." was the model into the 90s.
Related is the fact that programming moves fast. Building techniques change, but much slower than software. Most civil architects work all their life building similar constructions with similar materials. That lends to a lot more formalism.
Idk... I'll grant that there are a lot of downsides to openness. There are upsides too though.
On balance, I feel that software's rare status as a "free profession" in anachronistic terms, is good.
Also, I think that expansionary economics plays a role. There's more software work every day. Software developers aren't under the same economic pressure as other professions. Lawyers would be hurt financially if accreditations and qualifications were taken out of law.
It's hard to know what a world with licence to code looks like. Maybe we have a lot less software, but it's more secure. Maybe we know a lot less about the software we have.
Finally, I consider the importance of OSS, FOSS and volunteer made software a strength, not a weakness. That's a whole other thread though.
I use basically nothing of what I learned at uni to do my job. Everyone knows that the best devs usually didn't have any formal education. It's all based on merit - let's just keep it that way as it seems to work fine.
As a counter example - I'm currently living in Germany and I need a guy to fix up the walls of my house. Problem is it's impossible to find anyone to do it because there's not enough qualified craftsmen in the country. Everything is so tightly regulated that nothing gets done anymore, so instead there's a move towards folk trying to do it for themselves and buying materials from non-regulated big American-style hardware stores. Wouldn't life be better if we all had a broader skill set and were able to hack things together ourselves in an unofficial capacity like programmers do?
You mean like leet code, white bording and take home tests? Except that instead of being standardized/credentialized, every company has a different variation you need to study or do unpaid work, for every interview.
Yeah, good thing we don't have that kind of testing, this is so much better./s
We don't test our accounting candidates on advanced accounting theories. We just trust the certification and the experience on their resume.
But we ask our developer candidates with take home tests. I wonder why. /s
Anyone could build furniture without any licenses.
It's like anyone can be a salesman, but the more serious consequences something has, more regulation there is for selling it.
Regulation based on consequences already exists in IT sector as others have stated in this thread.
https://www.gnu.org/philosophy/right-to-read.en.html
Now Licensed and Bonded programmers are being proposed. Who thought this was science fiction, once upon a time?
RMS is a Cassandra of our time.
That seems like something that might make more sense if done minimally. For example, if we freely granted anyone who wanted a professional-license, then basically just publicly affixed warnings of blatant misconduct (like deliberately sabotaging an employer's code), then that might seem sensible.
However, professional-licensing schemes seem prone to becoming cartels.
Eventually we'll probably want a (web-of-trust)-like system to replace the ad-hoc strategies for vetting business-associates used historically. Professional-licensing bodies seem sorta similar in principle, though their heavy centralization/bureaucracy seems prone to corruption and chilling-effects while also being of questionable effectiveness.
Let’s start with the three major fallacies
1. Software Engineer is a monolithic profession. There are a great many specializations.
2. Software Engineering is comparable to trades and other engineer professions. Classical professions have existed for millennia, and are built on a foundation of failures through anti-fragility. We understand really well how to build houses and bridges. Software is a nascent profession.
3. Societal problems can be solved by software engineers. This is a problem of law and consequences. The Babylionians had a great thing with Hammurabi’s Code. When data protection laws will severely punish personal data leaks, then banks and other financial firms will take great expense to prevent them.
The issue of bugs doesn't go away from having more certification. Formal methods might be able to have an impact, but that can't produce software at the rate we need it produced to get real value.
No-one sat down and decided to use open source - quite the reverse, it rolled over any number of opponents by being more reliable in the long term and cheaper. If the same approach worked in other industries it'd be used there too.
There are situations where mitigating risks is absolutely necessary (again, healthcare is a good example), but in most cases, it’s best to let individuals decide how to best deal with those risks, taking into account their domains and resources to determine how to best produce value.
Yet it feels that building essential life- saving machines running on windows XP with internet access should be a crime.
I think if anything we need regulation on the industry-level so that e.g. plane controllers won't be running on operating system which can restart and update without users consent.
It would make prefect sense to require certain level of certification to work on code in some selected industries.
Ethics is at the core of all other Engineering disciplines, and there’s no reason we couldn’t regulate Software similarly. It protects the public.
Software (at least business tools) tend to be monetized/sold (at a high price) by corporations (that employ programmers that write these programs, and are well paid) as tools to actually do something.
When the something is not delivered (or it is not delivered correctly) there are consequences (time lost, money lost) for the customer/client that bought the tool (or subscribed to a service), as the tool is needed (or only useful) for the "main" activity of the client.
Yet - usually - neither the corporation (that gets the money from the client), nor the programmers (that get the money from the corporation) consider these cases as anything more than "oh, a bug, didn't see/foresee it".
In any other more material contract when you don't deliver the goods (or don't deliver them in time, or they are not up to the required standards/quality) you pay a penalty, and after you fail a few deliveries you are likely to go out of the market.
Somehow, in the software world, it seems like it is always a "oops, will fix next time".
The software we create is a direct reflection of the problem that is being solved. If you are hired by a small 3 person startup company to help them build an MVP on a budget for an untested business model, then you _should_ expect garbage, because that is precisely what is being asked/paid for.
Writing systems software for flight controls or similar use case where loss of life might occur? Well then you are _still_ being persuaded by a project manager and senior leadership to find a balance between cost and quality... but since lawsuits get more expensive when lives are lost, you have more quality control (yes, ethics should be more important than money, but that is not the case).
The _business_ makes the bulk of the decision on quality and safety, NOT the person in front of the keyboard. In most cases (web, e-commerce, SaaS, games, etc.), there is more business value to be had from releasing buggy garbage _fast_ rather than thoughtful and well tested features. You can always roll out a fix next sprint.
Our profession _is_ full of immature practitioners, and it has a long way to go if we are going to fix this, but there are powerful market forces at play currently and for the vast majority of us it makes more sense to _swim with the current_ and extract as much value from your career as possible... and if we can be spoiled brats that demand more vacation and free food/drinks, why not?
It's difficult to say which is better, 20 years ago we were more professional, but today we have a lot more leverage. I miss the professional attitudes and behaviour, but I've gotten used to the outsized compensation and easy job market, and in all honesty, wouldn't turn back. ¯\_ (ツ)_/¯
He claims that open source software trivializes our profession ignoring the fact that most of the time the open source as is software is the best there is.
He talks about all these examples of software falling boeings, financial firms, lunar landers which by the way are all not open source.
Additionally the boeing case was not even a software failure, if I recall correctly one of the sensors would physically get stuck in a wrong position, you know the kind of physical system designed by licensed engineers.
Then he proceeds to list a number of perceived problems in the software industry, failing to see that they also exist in other industries, these are not symptoms of lack of professionalism they are the reality of profit seeking taken to the extreme.
Liability is a thing, we don't need licensing because we are liable for the code we sell and the services we provide.
Licensing does not fix any of these problems all of the bridges that have fallen, all of the planes that have crashed have been built by licensed engineers, the solution in engineering has been regulations.
Almost all developers I know can make things work. They get the job done and thats fine. Like some people here wrote, for many applications thats enough. But already one "level" higher, density gets way lower. I only have my subjective feelings but as far as I can tell, developers who not only get things done but have a okayish code quality and an acceptable test coverage are so much more rare. True software master craftsman are almost not existing.
I guess our view of the software industry here is a bit distorted. Naturally people who are active here (or on other sites) dont represent the big mass of software developers. The top people in our software industry can keep it up with the top people of other industries (at least I hope and think so) but the entry and average level is not on the same level as the entry or average level in other industries. Thats where good and structured qualification paths can help.
So the first step in becoming serious is proving why one thing is important and why we should do it. I am experienced in a way, and I mostly really don't know. I've seen projects built real serious that were impossible to change and duct taped things that were a breeze. So it's not what most people think.
Most quality issues are down to economic constraints and priorities. It’s not hard to hire cheap degree qualified devs and set the deadlines so tightly that only garbage can ever come out of it. Most terrible software I have seen is terrible because no one cares to make it better.
Let’s not forget that historically a lot of licensing restrictions had more to do with protectionism and gatekeeping than with quality. Most countries have a long list of absolutely laughable restrictions that are justified by ridiculous claims about quality control.
I think where quality is an absolute requirement, it’s the software itself that should be inspected and licensed, not the developers. After all, users rely on software, not on degrees.
LICENSING WON'T INCREASE QUALITY OR SUPPLY Adding licensing to be a software engineer will not produce more or better software developers.
LICENSING OBSOLETE IN FEW YEAR The software industry changes very fast and that's also because it doesn't have a ton of beuracracy weighting on it (yet). Try standardising exams to be a software developers, then everyone will have to know a language or practice of 10-20 years ago! Already this is happening with universities that are stuck teaching Java while clearly everyone should have moved to Javascript/Typescript/Python/Go/Rust by now.
LICENSING ONLY GIVES ADVANTAGE TO SENIOR DEVELOPERS Finally, this type of licensing are also a way for the people already INSIDE to close the gate and allow less younger talent in to compete with them. Don't close the gate, move up in your career as software engineer and become an entrepreneur or manager and help younger developers rise up too.
Besides, software is a business that's surprisingly low on the bullshitisation that's taking over almost every other "serious" job, where people have ever less time to do their actual job and spend more time documenting how they do their job and justifying their choices with after-the-fact narratives that don't accomplish anything other than make someone look busy while producing nothing of value and increasing consumer costs.
You end up working for a year at $300k to produce something that yields tens of millions of dollars for the company. Bad fucking deal.
On the other hand, things like barbering, teaching, truck driving, blood drawing, supervisory civil engineering, and the like can't be contracted remotely, so they naturally gravitate towards licensure in many cases.
That didn't work out so great for Boeing.
And if marketability to airline executives and time to market dunk on the engineering culture then it doesn't matter who does the work and with what credentials -- there will be screw ups.
(this isn't an objection/rant to your post, it's just an opportune point to reply on how this relates to software quality)
There are people in the world that create things. Then there are people in the world that take those things, and figure out how to make money. Then they seek to direct those who create.
They take software and turn it to inappropriate ends, misuse it, abuse it, make it a panacea, a weapon, then a crutch. They build whole cities and societies around things they neither understand nor appreciate the origins of.
And we let them.
We build doll houses. They rent them out to a real family.
It isn't that software cannot be engineering, but to make it so we'd have to change a whole stack of human relations and the world doesn't seem ready for that.
I studied software engineering at the end of my CSEE degree and in 30 years, in all but a few medical/military applications where ISO documents properly govern _what_ is used, and _how_ it's used (not who makes it) I've been laughed at for even suggesting the principles I learned in software engineering.
Software is still an experimental rocket burning fuel as fast it can to achieve escape velocity.
There is not enough space in a short post to express how ridiculously I think the "software industry" is structured, but the solution is not regulation, which will make almost everything worse and kill innovation stone-dead.
The solution lies with us. When programmers have ethics and courage, enough to say "no", it will make a vast difference.
In the context of your statement, how are you defining "ethics"? One could argue that it's completely ethical to trade one's information or skills on a subject to the highest bidder. That's how a job works. What someone does with a knife or book doesn't concern a storekeeper after the purchase. Absent any evidence of one's rights being violated, what does it matter what another person chooses to do after one has been compensated? He has his life and you have yours.
>They take software and turn it to inappropriate ends, misuse it, abuse it, make it a panacea, a weapon, then a crutch. They build whole cities and societies around things they neither understand nor appreciate the origins of.
In this context, who is or should be the arbiter of "inappropriate", "misuse", "abuse", etc. ? I agree with you that many people don't understand the totality or consequences of what they purchase. But is that to be held against them as evidence of "unworthiness" or that they must patronized?
Really glad you asked that Dracophoenix! :)
Indeed, it's such an interesting and extensive topic that I am writing a book (aprox. 500pp) on it. You will be able to read it in a few months.
Meanwhile have a look at this one [1] which lightly touches on some of the issues that intersect ethics and code. Cheers.
Most in this trade work on a layer near the top (closer to the end-user) coding just a bit of logic and gluing together building blocks in order to provide a solution to real needs.
The trade seems trivial because the hard work (millions of lines of code) is already done. And that right there is the brilliance of the whole thing: take any layer apart and it will be done of smaller pieces which have been debugged to the point of being practically flawless (yes, we still find bugs in code that is out there for years, but that is the exception not the rule).
On the other hand, if you want accountability and guaranteed results, you have them already: formal software development processes used by the likes of NASA or the military.
Many accountants have non-accounting degrees, are self-taught, work without a license, etc. but a license is required to “hold out as a Certified Public Accountant (CPA)” and perform some regulated services.
The CPA license provides the skills/knowledge floor that other comments have mentioned so being a CPA offers signaling even if a role doesn’t require the license.
There aren’t any buildings falling or patients dying but all CPAs have annual continuing education requirements (including ethics classes) and the Code of Professional Conduct has a strong focus on maintaining public trust in the profession.
There’s a lot of professional judgment involved but most of the Code boils down to: keep the public interest in mind, act with integrity, be competent, do things your professional peers would deem reasonable.
Software development differs from other engineering disciplines dramatically: a blueprint/spec for a car or a bridge or a building is not in the same ontological category as a car or a bridge or a building: you cannot drive it or live in it.
However, a spec for a computer program is a kind of a program. It just requires "a truly smart compiler" (an SDE). This conceptual connection might explain the shape of the learning curve for software vs other engineering disciplines.
It was in line with “To accumulate wealth, you either have to exploit the planet, other nations or it’s own people. This applies for countries, companies and even individuals.”
That's an excellent way to put it.
Our regional Dental Surgeon association constantly runs ads encouraging people to become dental hygienist, explaining that it is a great career. It's obvious through why the association wants more hygienists - Dental office needs to hire and pay for Dental hygienists, which are owned by Dental Surgeons.
These days, tech companies and executives constantly encourage people to learn to code because it is supposed to be a great career. I couldn't think of other reasons beyond the obvious altruistic reason of just wanting to make everyone better off by guiding them towards this career. /s
Really, the issue is that many young people in software hadn't taken many social science or business courses so they hadn't seen how society/politics/business work until later in their career.
Still, it’s scary that to wield a pneumatic drill you need a license, but to suck in my personal data and store it on an unsecured S3 bucket you need absolutely nothing. To sign off a building you need a qualified surveyor, but medical records storage isn’t audited. Etc etc
Software developers are in shortage and we don't need to put any more roadblocks in the way of people who decide to learn it. On the absolute contrary we need to make it easier.
The only thing worse than the idea is how poorly it's argued.
Boeing's issues are not software related. Those planes crashed because of MacDonald Douglas's involvement and the lack of accountability _for management_ that followed. Also the FAA. Licensed software engineers wouldn't have fixed a systemic issue elsewhere. Plainly a stupid, irresponsible and irreverent opinion.
Hopefully the author reneges on this nonsensical idea.
If you’re wondering why people think software developers are seen as out of touch children, I don’t think professional licensure is high on the list tbh.
Can you imagine? “Please enter your license number and authorization code to use this compiler”.
No thanks, credentialists. I’m a better programmer than you. And part of that is because I don’t waste time trying to become an MSCE or whatever you’re trying to do.
The point isn't to abolish the certification mechanism. It's to prevent it from being compulsory. The certification mechanism is a way for people without anything to recommend them to find a credential.
Now imagine some busybody picks one and mandates it, legally, across the entire industry.
What a nuisance. Shoo!
It would be quite a bit better if most other industries eliminated licensing.
Because they become grab bags for random political whims that have nothing to do with ability to do the job:
https://www.nelp.org/publication/unlicensed-untapped-removin...
https://www.cato.org/policy-report/september/october-2018/ta...
Because they force workers to do hundreds of hours of unnecessary and expensive training:
https://nsjonline.com/article/2021/10/instructors-salon-owne...
Most of all we don't have any examples of nimble adaptable licensing, software development would not be some magical exception. For low innovation professions, where the knowledge doesn't change much over 20 years, licensing is bad. For a high innovation profession it would be crippling. What if when switching from Java to Python to Javascript you had to do 400 hours of training and sit for 2 days of tests each time? What if each of those transitions had taken industry an extra year to make because of excess oddball training requirements? What if certain members of your team couldn't "get up to speed" by being mentored on some system, but first had to be licensed before they could commit any code at all?
Far better for other occupations to copy our very successful one.
And as life advice, avoid any profession that does require licensing, it is usually a bad deal.
Anyone who does app security via a static bullet point list is bound to produce a sieve. And licensing is usually a series of bullet point lists.
> Anyone who does app security via a static bullet point list is bound to produce a sieve. And licensing is usually a series of bullet point lists.
It would be improvement over current "app security via ignoring it" approach.
I’m so sick of giving basic FizzBuzz and watching people with “10 years” of experience fail. I’m sure the competent developers want to stop wasting their time taking FizzBuzz!
We’re looking for a floor, not a ceiling.
It’s remarkable to me how many people do fail. I get that there’s pressure, but a huge part of being a senior dev is overcoming that to lead.
* Completely freezing / not coming up with any way to approach the problem / admitting they don't know how to code?
* Failing to use the basic tools, i.e. keyboard, text editor, compiler (please don't say you do whiteboarding)?
* Failing to produce code that compiles?
* Failing to produce an implementation that even approximates correct behavior?
* Failing at minor details / edge cases / reading comprehension?
* Failing at providing an unit test?
* Failing at code quality even if their solution works?
* Failing at explaining their solution?
* 1/3rd of interviewees freeze up and wouldn't be able to add two numbers together if asked. This is, to me, is mostly indistinguishable from, "have never coded in their life and lied successfully to get this far."
* 1/3rd only partially freeze up and produce an incomplete solution and can't talk their way through what they did and why there's a missing piece
* 1/3rd are able to get through FizzBuzz but with great frustration (they're usually upset with themselves for struggling so much).
None of these failures are acceptable in an engineer with any amount of experience, even though they're not all strictly speaking about ability to work with data structures and algorithms in a vacuum.
The thing is, software development is a team sport, and you have to come ready to play. If the goal was to find the person with the absolute best ability to take a set of static requirements and turn them into functioning code by themselves, this would not be a fantastic test. That is not, however, how nearly any software job actually works.
What was your point?
Software developers sometimes work on critical infrastructure—and licensing there does make sense. But requiring a license for me to build a silly web app seems like a classic example of what people complain about when they complain about unnecessary government regulation.
Yes, "shipping is a feature", but "it compiles" is not enough to just "ship it": you need to spend serious time to test it.
I'm sure you all can come up with more examples
When you build a shitty website, generally no one really gets hurt.
I asked the other scribe at the temple if anyone can learn to read, and here's the first result:
Anyone can be literate — it's not magic. You don't need to be a pharaoh or a priest to solve writing problems in the real world
No other profession that I'm aware of trivializes their profession to the degrees that scribes do. Scribes should be licensed and be bound by a professional ethical code where violation of said code would result in the revocation of the license to practice reading and writing.
— ⁂ —
http://www.cs.cmu.edu/~Compose/bok_assessment.pdf
In May 1999 the ACM Council adopted a resolution both reaffirming ACM’s commitment to solving the software quality problem and also stating its opposition to licensing software engineers, on the grounds that licensing is premature and would be ineffective in addressing the software quality problem. ACM Council also affirmed its interest in developing a core body of knowledge for software engineering, which is often viewed as an appealing step toward improving software quality. Our committee was formed to study the existing software engineering body of knowledge efforts — including SWEBOK, with which ACM is involved through the joint IEEE CS/ACM Software Engineering Coordinating Committee (SWECC). Our charge was to determine the status, progress, and likely outcome of these efforts. This report documents our findings, our reasoning, and our conclusions.
Our study and analysis has led us to the conclusion that the current software engineering body of knowledge efforts, including SWEBOK, are at best unlikely to achieve a goal of critical importance to ACM: the ability to provide appropriate assurances of software quality for software systems of public interest. Although the body of knowledge efforts may possibly make progress towards other stated and unstated objectives, we believe that ACM’s continued participation in the SWEBOK effort will not further — and indeed, may distract from — efforts to improve software quality, especially for systems of public interest. It would be consistent with our analysis for the ACM Council to choose to withdraw ACM from further involvement with SWEBOK, largely because of the danger of pursuing a path that might well provide false assurances to the public. Furthermore, we are uncertain whether, at present, there exists any process to articulate a core body of knowledge in software engineering that will directly contribute to the solution of the software quality problem. At a minimum, a conceptually clear and generally accepted organizing principle is a necessary pre-condition to the effective articulation of such a software engineering body of knowledge. No compelling organizing principle exists at present, and we see no clear course of action that would be likely to lead to one in the next few years.
— ⁂ —
That's from 02000, but unfortunately the situation hasn't changed since then. The IEEE continued promulgating the SWEBOK, but it's nothing more than a bunch of snake-oil methodology salesmen seeking unearned credibility for their fake project-management panaceas. We do have a few pieces of software that may have achieved reasonable quality for "software systems of public interest", like seL4 and CompCert, but it's still an extremely fringe activity.
— ⁂ —
The bigger issue is that computers are now our exocortices; we've offloaded significant amounts of our thinking and communication onto them, as we did previously with inventions like books and clocks. Computers vastly extend our mental abilities. Without control over our computers—without the legal and practical ability to program them and to investigate what they are programmed to do—we in effect lose our freedom of speech, association, and thought. That power is far too dangerous to allow any guild or faction to monopolize it.
— ⁂ —
The closest I've seen to a well-thought-out professional ethical code for software development is https://www.gnu.org/gnu/manifesto.en.html, which motivated the development of much of the infrastructural software we rely on every day: GCC, glibc, bash, GNU grep, GNU xargs, etc. Its core value is giving end users control over their own computers; this is completely incompatible with Huntley's point of view, not to mention much of current industry practice. But its main problem is that it doesn't go nearly far enough, having been written too early to contemplate issues like DRM, IoT, the commercialization of the internet, spam, and centralized online identity providers.
Nope. You're done.
It would kill creativity, exploration, and innovation of those who are unlicensed. You don't need a PhD to start on the path, and since software is as broad as every other industry and has many different approaches, it is futile to try to set boundaries and limit it.
Is someone who prefers strict functional programming not worthy of certification? The "certification" would tend to favor the current dominant styles, which would be enterprise-y procedural-ish stuff. I don't think that would be a boon to the state of the art or to progress.
Codes would exist for safely handling them, just like building codes for safely building a structure.
And no the code wouldn’t include functional vs object oriented programming, just as a building code wouldn’t specify the building’s paint colour.
You pretty much start with the most important stuff, exactly as you suggested. That's what the market wants. See this history of engineering licensure (https://www.nspe.org/sites/default/files/resources/pdfs/pema...): It was originally enacted to stop lawyers and random people claiming to certify the design of huge infrastructure projects for dams and irrigation, where the consequences of failure would be flooding huge areas, causing immeasurable damage. For the same reasons, if you're building dams or nuclear power control systems etc today, I imagine you'd be looking for a similar licensing system. Maybe you would simply use the licensing systems that already exist.
The rest of your comment sounds a bit like "it is oppression of my creativity when I build bridges that are made out of four thousand spoons tied together with craft glue and the NTSB says I am largely to blame for it falling on a pedestrian". It is obvious this far into the discipline's history that some things are good ideas and some things aren't, and it is possible to say that if your new 6-week-coding-bootcamp hire doesn't know anything about password hashing you should not give them the job of rewriting the login page. Nobody cares if you write it in Haskell, nobody's trying to draft statewide RIIR legislation, and you are KIDDING yourself if you think that your rebellion against enterprise-y procedural-ish stuff is more important than not letting Russian hackers steal all of your users' sensitive data and sell them to others who will blackmail them for more cash.
The market forces are in favour of accrediting the people who work on systems that are important to avoiding pretty dramatic harms, and even death and destruction. People aren't dumb and will eventually wise up enough about the shoddy work that gets done to start suing engineers behind data breaches for negligence (more). You're here proving the article's point by not taking this profession seriously enough to see that even a limited licensing scheme could be warranted.
What is needed is licenses for those who _deploy_ software in critical applications. They should be audited to hell and back and face catastrophic liability for failure.
We already are moving there, creating a small number of well paid, highly skilled senior positions who have 40+ years in software and full ISO9000/27000. It's a chartered quality assurance role that overlaps cyber-security/safety and resilience engineering.
And we must remember, that despite construction work being regulated to the hilt, we still got the "cladding scandal" and Grenfell Tower fire in the UK. Software "safety inspection", where appropriate, must also be a thing.
Something the article did poorly is its analogy between software engineers and solo tradespeople. That's the wrong end. There is very little danger in having solo software engineers working unlicensed; they're out there making Wordpress websites and apps that are also basically information websites. Solo tradespeople are doing electrical work that might start a fire and kill a family. There is a big difference at the low end and it is bad to compare those two classes of worker.
Software is intangible and has fewer requirements which obviously helps with speed but the normalized pace of output doesn't seem significantly different. Large and complex software products with equivalent real-world reliability also take a very long time.
That is fundamentally untrue. In fact, regulations would even the playing field. Right now, anyone can get their Engineering degree, complete an apprenticeship, and open a firm. Regulations like Building and electrical codes protect the public, and certified civil and electrical engineers are certifiably competent enough to implement them. Once certified, everyone has the qualifications to bid for the same contracts.
Great, then we should see that. We don't, because that's not true. To "open a firm" with all that red tape requires a great deal of people, namely lawyers and other engineers. That's big money, and it looks bad in comparison to the larger company that, again, gets to set all the rules for you.
Certifications are junk. They're a belief system the same as religion. All anyone has to do to be an engineer is get a degree. Do you see how many people have advanced degrees and have nothing but air between their ears? Yeah, I wouldn't trust them to make a popsicle stick bridge.
The reason for all the certs, degrees and requirements is control from the largest of corps. They want to set the standard to prevent competition and convince people they are the safe and effective option. You can't compete unless you play their game.
A PEng needs thousands of hours of work experience then need to write competency exams. Religion? What are you talking about?
But people can and do start learning on their bedroom computers, and it's to be encouraged. Such self-taught people can make very valuable contributions, especially when they engage with the wider community. Locking them and their output out "because engineering" is likely to be massively counterproductive.
Like as not, software is different.
They should try being like us!
Okay, how about you build a list of software that directly killed people and I'll build a list of non-software that directly killed people in 2021. Then whoever finds more people killed gets $10k from the other? We can agree to terms of what it means for software to kill and non-software to kill. Therac-25 is obvious software, Florida condo collapse is obviously hardware.
Besides, few pieces of non-engineering is responsible for massive data breaches that lead to massive indirect consequences, such as Equifax. Perhaps your obsession with death overlooks other consequences of poor software engineering like financial ones, such as Black Monday, 1987. Perhaps bad software kills fewer people because less software engineering is involved with real-world systems- though requiescat in pace to those lost to Tesla Autopilot accidents, or the unfortunate biker in Arizona struck by a self-driving Uber.
I am transparently moving the goalposts here because your presumption that fatalities are the only consequence of shoddy software engineering was fallacious to begin with. Pray I do not move them any further.
All this without licenses.
Ethical code? You mean laws?
How would you enforce this? Wipe compilers from one’s computer? Interpreters? Remove shells?
You can't have it both ways.
Either the writer doesn't understand the importance of words or they aren't being intellectually honest. Replacing his query with, "Anyone can be a software engineer". The first result I get is from Quora and there is a whole range of responses.
I do think there is a more nuanced argument to be made that some types of software engineering, may need regulation (air traffic control, medical devices, cars, planes, nuclear power plants) to the extent it doesn't have it already, but I don't think this article is being thoughtful enough to make it.