If this blog post had been written 4000 years ago, it might have said:

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.