Coding Freedom: The Ethics and Aesthetics of Hacking

defended the general use of RTFM, concisely enunciating the value of self-determination:
    When the code is public, rtfm is the proper answer. One might add “document it properly afterwards” as well, though. When the data is available as well, that’s best. Some data cannot be made available for legal or other binding obligations (new queue, security archive). If you feel that some bits are missing and need to be documented better, point them out and get them documented better, maybe by doing it on your own. I know a lot about the project because I’ve been involved in many parts. Other developers are involved in many parts as well. Some other developers mostly whine about not being involved without trying to understand. *sigh* 17
    In other words, if the requested information is public, it is incumbent on the developer to seek it out, and if unsatisfied with the current state of accessibility, then the next logical step is to make it happen—by yourself. If one does, one can display self-determination and self-development, the vehicles by which to gain the respect of accomplished peers on a similarly paved technical path.
    If the subject of elitism erupts on mailing list discussions over project organization, a form of stylized boasting, taunting, cajoling, and elitist disdain is also frequently performed through code. Here I provide two examples. And again note how humor is used in both, to some degree working to soften the abrasive tone of these messages.
    The first one is written in the style of an “I-can’t-believe-how-idiotic-this-problem-I-have-to-solve-is rant” that disparages a bug in the Emacs email reader. Before addressing the significance of his code, permit me defer to the coder, Karl Fogel, to explain the context of the problem and the technical nature of his solution:
    Basically, the mailreader insisted on colorizing my mail composition window, even though I tried every documented method available to ask it not to do that. In desperation, I finally wrote code to go “behind the back” of the mailreader, and fool it into thinking that it had already done the colorization when it actually hadn’t. 18
    The comments open with a statement of disbelief; take note of the naming of the variable, which I highlight in bold and italics:
    ;; I cannot believe what I have to do to turn off font locking in mail
    ;; and message buffers. Running “(font-lock-mode -1)” from every
    ;; possibly relevant gnus-*, mail-*, and message-* hook still left my
    ;; reply buffers font-locked. Arrrgh.
    ;;
    ;; So the code below fools font-lock-mode into thinking the buffer is
    ;; already fontified (so it will do nothing—see
    ;; font-lock.el:font-lock-mode for details), and then makes sure that
    ;; the very last thing run when I hit reply to a message is to turn
    ;; off font-lock-mode in that buffer, from post-command-hook. Then
    ;; that function removes itself from post-command-hook so it’s not run
    ;; with every command.
    (defun kf-compensate-for-fucking-unbelievable-emacs-lossage ()
    (font-lock-mode -1)
    (remove-hook
    ‘post-command-hook
    ‘kf-compensate-for-fucking-unbelievable-emacs-lossage))
    (add-hook ‘font-lock-mode-hook ‘kf-font-lock-mode-hook)
    (defun kf-font-lock-mode-hook ()
    (if (or (eq major-mode ‘message-mode)
    (eq major-mode ‘mail-mode))
    (progn
    (make-local-variable ‘font-lock-fontified)
    (setq font-lock-fontified t)
    (add-hook ‘post-command-hook
    ‘kf-compensate-for-fucking-unbelievable-emacs-lossage)
    )))
    By opening the comments with “I cannot believe what I have to do” and ending with “Arrrgh,” he signals the fact that this sort of trite problem is so idiotically banal, it should have never appeared in the
first place
. Fixing it is a waste of his superior mental resources. Lest there be any ambiguity as to what the author really thought about the code, he continues to drive the point home in his rant by naming the variable with an unmistakably deliberate insult: “compensate-for-fucking-unbelievable-emacs-lossage.”
    During the course of my early research, I was shocked at the disjoint between the in-person real-world “codes of conduct” and the “codes of software conduct.” Nothing about this coder’s personality, who I got to know very well over the course of five years, would indicate such haughty declarations. There is no need for such an indication because these enunciations are rarely a matter of innate psychology. Instead, these are conventionalized