I often have imaginary conversations with real people. No, this isn’t evidence of some kind of schizophrenia. Nor is it some kind of Zelig-style wish fulfillment. It’s more like what I do in chess or in designing code to deal with failures, anticipating things that people might say and how I might respond. Most of the things I anticipate remain unsaid, of course, but sometimes I guess right and it’s nice to have my response be thought out instead of ad hoc. As I re-read one of my recent comments, I was reminded of one of my favorite observations about the business I’m in.
“Familiarity breeds contempt” is even more true in computing than elsewhere.
Have you ever met a decent programmer who didn’t express contempt for at least 90% of Other People’s Code that they worked on? I’m not sure I have. Novice programmers sometimes fall prey to the notion that since they’re so smart then anybody who thinks of even one little thing they hadn’t must be a total genius, and engage in bouts of hero worship for whichever programmer most recently taught them a new trick, but most people outgrow that pretty quickly. Usually “it doesn’t suck” is the best thing an old-timer has to say about any code or other piece of technology. It is, of course, a short step from that attitude to the well known “Not Invented Here” syndrome, in which one foregoes use of an existing technology in favor of a similar one developed locally. Sometimes the local variant really is better, but almost never enough so to justify the expense of developing it. This brings us to NIE, which is NIH’s evil twin based on the following observation.
We apply NIH to problems we think we know how to solve ourselves, and NIE to problems we’ve given up on solving ourselves (not that we’d ever admit it).
NIE is a variant of “magic bullet” thinking, and it goes like this. “I’ve worked with technology X, and hate it. Technology Y competes with X. I haven’t used Y and haven’t learned to hate its quirks or limitations. I’d rather use Y, because it makes all my problems with X go away. Since I want to use Y, everyone else should want to use Y.” Obviously there’s a lot wrong with such so-called reasoning, from violating the “devil we know” principle to assuming that the hypothetical speaker’s experiences or preferences can be generalized to everyone, but it’s how a lot of technical biases become entrenched.
An awful lot of advocacy, from Perl vs. Python to IB vs. 10GbE, comes down to either NIH or NIE. Does fear of the unknown or contempt of the known win out? If it’s fear, then NIH will rule the day and the more familiar alternative will be favored. If it’s contempt, then NIE will win and the Shiny New Thing will be pushed instead. That’s why I think we engineers should actively battle both fear and contempt when making our technical decisions. “But Jeff,” you say, “you spend a lot of time casting aspersions on everything you work on.” Yes, I do, because this is my outlet for such things. I rant here, then I go back and work on the very technologies I rant about because I recognize that the alternatives almost certainly have their own problems. Sometimes I push for a change of direction, sometimes I even set off into the bush with a machete to create a new direction, but I never assume that life will be easy either by staying or by going. The real problems don’t go away just because of what technology I choose, and I’d rather spend my work time solving them than wishing them away.
Speaking of which, I’ve spent enough time writing this.