ego.istic.org

While I was visiting my parents last weekend (to celebrate my birthday), my aunt voiced the opinion that I am wasted in programming as my real gift is in explaining difficult concepts.

I agree to an extent. My boyhood ambition, in terms of what I wanted to do when I grow up, was to become the sort of person who goes on Horizon and makes physics sound exciting. I failed at that by leaving academia before getting to that stage, but in any case, Horizon is not very good these days, and by the time I were to discover anything, science programming may well have gone the way of radio lectures. (Please don't start leaving comments to tell me that radio lectures still exist: I know Radio 4 still broadcasts the Reith lectures every year, but this is nothing compared to when Lord Reith was still around, before proper radio programmes had been invented.)

Readers of this blog will probably already have judged my ability at explaining difficult concepts. Perhaps you agree with my aunt that I have some skill in this area; that is certainly my view. But on two other counts, I disagree with her completely.

For a start, I think it is my secondary skill: the thing I am really good at is learning. I don't mean learning in the boring sense of committing data to memory, but in the sense of quickly absorbing concepts, synthesizing and understanding them, and being able to apply them to other tasks. In a sense, this is the transferable skill, and it underpins all of my more specialist skills, because it is how I acquired each of them. It's a useful skill for a programmer, as it means he can produce a mental model of systems he has to interact with by swallowing the documentation for them whole, or by merely observing them from the outside. It means he can often spot bugs from the tiniest details just by intuiting what is likely to be wrong, which I find a particularly fun activity. It's such a well-regarded skill among programmers that it is even described in Appendix B of the Jargon File:

Although high general intelligence is common among hackers, it is not the sine qua non one might expect. Another trait is probably even more important: the ability to mentally absorb, retain, and reference large amounts of ‘meaningless’ detail, trusting to later experience to give it context and meaning. A person of merely average analytical intelligence who has this trait can become an effective hacker, but a creative genius who lacks it will swiftly find himself outdistanced by people who routinely upload the contents of thick reference manuals into their brains. [During the production of the first book version of this document, for example, I learned most of the rather complex typesetting language TeX over about four working days, mainly by inhaling Knuth's 477-page manual. My editor's flabbergasted reaction to this genuinely surprised me, because years of associating with hackers have conditioned me to consider such performances routine and to be expected. —ESR]

When I worked for Autonomy, it didn't take long for me to become the person they looked to to solve problems that no one had the knowledge to solve: for instance, obscure bugs in software whose original author had left the company long ago. On one occasion, there was a tricky deployment at a customer who had bought the software with a hefty service contract. When the field service engineer installed the system, it didn't work, and he called in help from the developers. The person who wrote the faulty component was given remote access to the server in question, and spent a week looking at the matter without success. It passed up the hierarchy of blame to the Head of Development, who in turn spent about a week trying to track down the problem. The matter then came to me. After getting access to the server, it took me less than a day to amass the requisite information from such source code as was available (the documentation being useless) and track the issue to its source, which turned out to be a very simple error. This is just one example of how useful the skill of mopping up information and turning it into useful understanding is in the software industry; I could relate many more.

The combination of both being able to absorb information and structure easily, and being able to explain it comprehensibly, is a real killer. With both these abilities together, I can do things such as listen to a vague, hand-waving, technical explanation of a hard concept I have not previously come across, and on the spot translate it to a simplified but accurate explanation for a non-technical listener or reader. I can listen to a plan for or description of a piece of software, and quickly come up with an analysis of its pros and cons, and describe same for listeners who may not have understood the original description. It makes me quite good at writing documentation that gives the detail that technical users want and also the broad sweep that lay-persons need, after even a brief acquaintance with the product being documented.

This comprises my second objection to my aunt's model of the situation: the ability to explain things clearly is incredibly useful for programmers, and rarer than what I think of as my bigger skill. Businesspeople try their best to make up for programmers' inadequacy at this: by keeping us away from customers and investors where possible; by trying to learn the application domain (be it computer graphics, financial modelling, or social networking websites) from industry magazines and other third parties instead of the programmers themselves; by employing tech writers to write documentation, and expensive consultants to run user groups and product design meetings. That they have gone to such lengths demonstrates that a programmer who can also act as an interpreter is a rare and prized find. So, I don't think I am wasting my life in the wrong career.

That doesn't mean I don't try to find the best niche to fit my talents, be it in a programming context or elsewhere. All the cool people invent their own professions, and I would be happy to come up with a specialization that allows me to remain a generalist. For some years I have thought that computer science needs a populariser, and indeed, the area of engaging with the public is an obvious one when you consider these two skills. Perhaps one day I will become a computer science journalist, a competent one, and turn my hand to writing descriptions of pressing issues and exciting developments, descriptions that are neither laughably simplistic to computer-savvy professionals nor incomprehensibly technical to the public at large. Or perhaps I will follow the example of Sherlock Holmes and write a “trifling monograph” or two. But, as my aunt was careful to point out, I am young yet, and I am happy enough where I am, in an industry that prizes both my transferable skills and the specialist knowledge I have used them to gather.