When I got out of college, I didn't have a CS degree.  Although I had done a little hacking in C, Emacs-lisp, and perl, I didn't think I had the skill required for an entry-level programming job.  (Now that I have a closer view of the software industry, I think maybe I was too hard on myself, but I digress.  :-)  So ... a few years after graduating, I started working for a hospital as a tape transcriptionist.

I did my transcription on a DOS machine running WordPerfect 4.1.  My predecessor had defined some WordPerfect macros for commonly-used medical terms.  After a while on the job, I wondered: "With so many common medical terms being used here, what is the optimum set of macros to use for my job?"

And then I thought: "I have a computer.  There ''must'' be a way to solve this problem with a computer program."

So I copied a week's worth of typing into one file, brought it down to BU (where I was going to graduate school), and tweaked a concordance-building C program I had used for a class (which was itself based on a word-sorting program in ''Practical C Programming'').  My new program printed out an alphabetized list of all the words in my source file, along with the number of keystrokes I would save if that word were a macro.  I loaded the output into emacs, sorted the lines, and voila!

Then, in WordPerfect, I twisted the macro language into giving me four-keystroke macros for a few hundred commonly-used words, both with and without capitals.  For example, typing ''H E alt-J'' would print out ''hepatosplenomegaly'', and ''H E alt-Z'' would print out ''Hepatosplenomegaly.''  I printed out my macro list, put it up next to my monitor, and went on happily cranking out letters for another eighteen months or so.

Now, I think that a lot of other people in low-level clerical positions have been in similar situations, i.e., some aspect of their job has a problem with the following characteristics:

	* It could be captured or analyzed by a procedural or functional abstraction.
	* There is no "shrink-wrapped" program that solves it, because the potential market is too small (perhaps the repetition is peculiar to one individual), and the worker(s) affected understand the problem better than a programmer on the outside.
	* Solving the problem does not require clever CS tricks or insight; anyone with a basic knowledge of Perl, Visual Basic, or a similarly powerful language could hack a solution together in 100 lines or so of code.

If more people in lower-level clerical jobs knew some general-purpose programming language, and if their work environments allowed them to use it to automate their tasks, then everyone would benefit.  The clerks would be more productive and less bored with their jobs (and who knows, might even end up better-paid).  Customers would get more efficient service.  Trained and competent programmers could focus their efforts on more interesting problems.

So why isn't this happening already?  I can think of a few potential culprits (all of which, of course, interact):
	* In the popular mind, computers have an aura of fear and mystery around them.
	* Computer education in the public schools is atrocious.
	* When end-user applications do have some extendability, it's often through a weak and over-specialized macro language.  (Maybe this is changing now, with things like VBA and Applescript.)

Other culprits?  How can this situation be improved?
----
Most programming languages expect too much abstraction for most people, and less than most programmers would like.
-----

See the discussion in LanguageUsability and FromCraftToEngineering
--------
See also: ComputerProgrammingForEverybody