Even without a nitpicker’s corner, I have to worry about nitpickers. I just have to do it in a more subtle way.
Here are some examples of changes I’ve made to upcoming entries in order to forestall nitpicking:
|Original text||Revised text||Reason|
|… entries in our list…||… entries in our table…||The entries are kept in an array, but writing “list” may cause some people to nitpick that an array is not a list.|
|… this function returns X…||… this function can be asked to return X…||The function returns different things based on what the caller requests, but the only case we’re interested in right now is the case of X.|
|… X affects only Y.||… X typically affects only Y.||Again, I have to add the qualifier to protect against the case where a program intentionally broadens the scope of X.|
|… X isn’t a problem because…||… X isn’t usually a problem because…||There can be cases where X is a problem because the program explicitly created the problem for itself, so I have to put in a qualifier. Indeed, later in the article I give an example of how a program can cause this problem, so I’d better leave myself some wiggle room at the expense of rhetorical power.|
|… a holiday….||… a holiday in the United States…||Otherwise somebody would make some smart-alec remark like “It’s not a holiday where I live.” [Typo fixed: 10am]|
|… the kernel ….||… the exception dispatch code…||To avoid confusion between “the kernel” and “kernel mode”.|
|… 64KB …||… about 64KB…||Because the limit is actually 65280 bytes.|
What’s scary is that I’ve noticed that I begun pre-emptively nitpicking my own entries while I’m writing them. In the balance between writing something that reads more naturally and something that is more resiliant to nitpicking, I’ve unfortunately started preferring the latter.
Observant readers may have noticed that I’ve slowly introduced a section called “Pre-emptive snarky comment” wherein I try to anticipate drive-by “Hey wouldn’t it be hilarious if I ridiculed Microsoft on a Microsoft employee’s blog?” comments. It seems to be largely successful, although sometimes people will post the identical snarky comment that I pre-empted. These are probably the people who talk just to enjoy the sound of their own voice.
An extension of this is the “Now that you brought up something that sucks, I’m going to tell you that it sucks” phenomenon. This is pretty much guaranteed whenever I bring up anything that is related to UAC and security, since it appears that everybody agrees that UAC sucks, so any blog entry that talks about elevation invariably leads to comments about how UAC sucks. There are also popular tangents, such as any article that mentions installing software turning into a “post your complaints about setup here” thread.
Some people are more indiscriminate and merely bash Vista whenever they get a chance, such as using a story about the psychology of how people fail to process information that they see to rant about how it’s hard to copy text out of the event viewer.
(That article about how people fail to process information that they see was indeed an unmitigated disaster. Everybody got into arguing over how the message should have been presented so the user would be more likely to see it, but that completely misses the point. The user positively confirmed, “I see the yellow warning.” The problem wasn’t that the user didn’t see the message; the response confirmed that the user saw the message just fine. What the user didn’t do was process the information. It’s my fault for choosing a bad title. Instead of “People can’t see things that are right in front of them,” I should have titled it “People see things but don’t pay attention to them,” opting for precision even though it meant I couldn’t use the idiomatic phrase can’t see what’s right in front of you. What made it worse is that I fell for the trap. I responded to the details instead of saying, “Whether your suggestion would have helped the user see the message or not is totally irrelevant to the point of the article.”)
I also hadn’t predicted that my discussion of how reasonable people can disagree about how a setting should be exposed would turn into a discussion of how to shut down your computer, turning a footnote into the primary topic of discussion. But that’s a fairly common occurrence: People focus on a side detail (which I added for color) and ignore the point of the story. Sometimes I think I’d be better off if I didn’t give examples. That way nobody could be distracted by them.