I AM NOT A PROGRAMMER

The Linux‐using world has always had a bit of an image problem.  Somehow the general public has got the impression that Linux is only meant for socially incompetent elitists.  Part of the problem here is that software developers have a characteristic skill‐set with its own implicit value system, applicable to real‐life problems as well as programming, and feel a strong common bond with others of their kind; as a result, they have a hard time empathising with outsiders.  (When people wearing ties do that, it's called a “professional attitude”.)

Now, I respect those skills and feel a great deal of gratitude to that community; but I'm not a member, never will be, never want to be, and never want to be told I should want to be.  I am not a programmer, and feel no more tempted to become (for instance) a kernel‐hacker than to become a graphic designer or forensic dentist.  This idea that Linux has ordinary mortal end‐users with no trace of a Computer Science degree may come as a shock to the man in the street; the more annoying thing from my point of view is that an awful lot of the people writing and maintaining software for GNU/Linux seem to have trouble with it too.

In the hope that it might help developers get a feel for what other kinds of people there might be in the wide world of Open Source Software, let me introduce myself.  I was never the kind of kid who owned a home electronics kit, a ZX Spectrum, or even a programmable calculator; my A‐levels were in Latin, French, and English Literature, and my degree was an MA.  I just happen to have worked my way up from guest login to command‐line power‐user to Debian GNU/Linux systems administrator.  I've been writing shellscripts for years; but that's a very different thing from programming!

• I can handle interpreted procedural languages, because I'm familiar with life on the Bash prompt.  But I do not mess about with memory management; I know nothing of lexers, parsers, compilers, linkers, fluffers, profilers, or debuggers; and “inherently object oriented” means “bafflingly counter­intuitive”!
• If you WTFM, I'll RTFM, but I do not RTFS any more than I'll RTFB.  Any application that requires fluency in C should at the very least be filed under “devel”.  So “it behaves just like standard POSIX getasdfghjkl” is not what I call documentation.
• I'll happily spend hours faffing about with ~/.foorc in a text editor.  (I don't want to have to do it in an IDE with code‐editing features; vi vs. emacs?  A plague on both your houses!)  However, if the config‐file's written in some esoteric syntax I can't get my head round, I won't dream of recompiling the binary, I'll probably just look for another package with better defaults.
• I do not need to know anything about libraries – that's the package management system's job.  I do not leave copies of the unpacked kernel source lying around, and have little grasp of what header files might be.
• I do not touch make files, except when I'm using make-kpkg to turn a linux-source Debian package into a customised linux-image Debian package, and even then I handle the whole baffling ritual through a wrapper script.  [2014 PS: and these days I've stopped doing that.]
• I have no use for revision control.  Not even when I'm writing a Perl script – there are no code‐forks to merge, it has no intricate compilation dependencies, and I keep good backups; why would I want to have to pass things through a repository before I can use them?  And as for those .cvs directories… [2014 PS: git is like one of those Edwardian spring‐loaded sweetbread‐slicers – it looks ingenious, but I can't imagine needing one.]

I'll concede that I'm something very like a programmer… I'm hairy enough, for a start.  But when approached from the non‐CS‐degree side, the slope is nowhere near as slippery as my codehead friends all seem to assume.