# On Where the Computing Priesthood Originates

Someone on Mastodon recently asked a question, paraphrased, "I don't get this
whole computing priesthood thing.  Where does it come from?" It comes from
cocky people who think they know more than anyone else.  But, that group
of people isn't who you think it is.

It's people like you.

I don't say this to be mean or pretensious; it's just how the history of
computing worked out through history.  You just happen to be part of that
history.

You see, the notion of a priesthood originates from the intersection of two
things: The human propensity towards anti-intellectualism (even little bits
sprinkled here and there), and how costly access to computers were upon their
introduction.

Mainframe programmers of the late 1950s to early 1970s were restricted in how
often they could access a computer.  Access to the computer was extremely
costly, and thus very tightly controlled.  Computers back then consumed tens to
hundreds of kilowatts of power (not counting the air-conditioning units
needed to keep the data center cool!), so you can well imagine how much even
one second of compute time actually cost a company that rented the computer.
Oh, did I mention that computers were often rentals?  Equipment failed
so frequently that it was cheaper to rent them (which often came with on-site
support contracts) than to own them and pay your own support staff.

Assuming engineers knew what code to actually write, they would often punch
their source code into physical stacks of paper cards during the day using key
punches.  They then would hand them off for compilation over night, when the
need for compute power was least in demand.  That's right: compilation (and,
thus, all of development itself) was considered a background task to be
performed when the computer had nothing better to do.  This begs the question,
why?

Let's pretend that it takes the computer about two minutes to compile or
assemble a relatively simple program.  This isn't unreasonable if you've ever
had the chance to play with time-accurate emulators of old computers.  That's
120 seconds of CPU runtime.  If the company was paying $100,000/month
to have that computer on-prem, each second of compute time costs $0.038.
Thus, to compile a single program, you're looking at spending a whopping $5,
give or take.  Those precious minutes spent compiling code were precious
minutes the computer wouldn't be calculating invoices or printing out
shipping labels or tracking inventory.  You've spent $5 in compute-time, plus
the $2-$5 in card stock, plus whatever your engineer's hourly wage is for that
day, but you've now lost the income that would have been generated by
those invoices and shipping labels, which usually amounts to thousands or more.
Now you know why compiling tasks were considered background tasks.

With turnaround times measured in workdays, you can imagine that programmers
developed really good mental models of the computers they were coding for, of
their programming languages (if they used any at all), and all manner of
heavyweight conventions (which look to the untrained observer like magical
incantations) designed to help ensure their code works first time.  Over time,
it spawned all the usual software engineering conventions and process doctrines
you're familiar with today (waterfall, etc.), ultimately leading to the Software Engineering Institute itself.
But, I'm digressing, and might be worthy of another article some day.  Point
is, these developers became really good at static program analysis out
of necessity, not a personal desire for exemplarism.  After all, without even a
terminal much less physical access to a computer for their 8 to 10 hour
workday, what else would they be doing?  It is from these constraints that the
advice, You should have most of your program written before you even touch a
keyboard, is borne.  If you work with computer programming in any capacity,
you probably read or heard of this advice in some form or another over the
years.  Now you know why.

So, as you can see, trying to explain the realities of computer programming
to those not versed in its unique skillset is difficult, to say the least.
What every-day experience could they use to analogize with?  Precious little.
So, trying to explain these things to (relatively) unskilled, inexperienced, and,
usually, maths-phobic people is, as you might expect, extremely hard.  People 
don't like the idea of self-discipline, let alone the notion of discipline
imposed upon them from external, mechanical and financial, sources.  (So much so
that some programming language communities go so far as to call tools which
impose such discipline bondage and discipline tools.
It's insulting.  But, whatever.)  So, they ascribe success in this field
(at any level) to a fictional priesthood, a cult of engineers that intends to
control access to the machine as a way of retaining power (when in fact,
they too desire simpler methods of access).

Fast forward to the 80s and 90s, and now the idea of a priesthood is so firmly
embedded in our culture that it even motivates entire programming language
communities (e.g., Smalltalk, and their intentions to teach it to children).
But, in practice, even with a system as interactive, open, and mutable as
Smalltalk, you still end up with a barrier to entry which a lay person can
ascribe to the existence of a priesthood.  Go on; teach a child Smalltalk, and
observe how far they get.  They'll either be natural at it, or they'll move on
to other things more interesting to them and won't look back.  It turns out
that programming really is much more than just writing a few expressions in
your favorite dynamically- or statically-typed language.  Recognizing that this
is the case is where we see the birth of the priesthood.

So, as you can see, there will always be a priesthood.  And those
who don't understand it or why it exists in the first place will always be the
ones who simultaneously place unrealistic expectations upon us as engineers
(yeah, yeah, how soon can you complete this task?  Why can't you finish it next
Saturday?) and who antagonize us whenever they can't get their way (if
it weren't for those damned priests, this would all be a solved problem by
now!).  Both of these are born out of ignorance; but when you mention this,
people become extremely defensive or even hostile.  Anti-intellectualism at its
most subtle, yet most obvious.

If you want to defeat the priesthood, you need to first conquer
humanity's natural predilection towards anti-intellectualism at all
levels.  Believe me, as a (computing) priest myself, I would love nothing
better than to teach others what I know, and how to make them more self-reliant
when working with technology.  It would solve many problems, ranging from
putting numerous scam artists out of business to undermining rampant
techbro-ism.  It would also give me more time to work on new features instead
of dealing with old-hat problems time and time again.

And, that's just in the computing field.  Think of what this would enable in
other fields too.