Fact Checking
|
By nature I am not very meticulous which is not such a good trait for a programmer. On the other hand that trait goes hand in hand with a lack of patience for repetitive tasks, ala ADD/ADHD, which is quite common for programmers. So I have, over the years, had to train myself to be meticulous which does fit nicely, combined with a bit of obsessiveness, when it comes to my code. When I began writing technical articles, the obsessiveness and meticulousness came more easily as it was generated by the fear of publicly exposing myself if I made a mistake somewhere. Ask any of the editors at O'Reilly about what a pain in the rear I was throughout the process of editing my book. I read it 3 times - the book is over 800 pages, so that's a lot of reading. I sent 100 pages of notes about things to change when we had moved into the production stage. So an article in this week's New Yorker, Checkpoints by John McPhee, was an especially delicous read for me because it was about fact-checking. More specifically, the fact-checking process that goes into each article that they publish. After reading about the process, I realize that whatever I have gone through pales in comparison. McPhee quotes a long-time fact-checker at the New Yorker: "Any error is everlasting....once an error gets into print it 'will live on an on in libraries carefully catalogues, scupulously indexed . . . silicon-chipped , deceiving researcher after researcher down through the ages, all of whom will make new errors on the strength of the original erros, and so on and on into an exponential explosion of errata." That is certianly a huge worry, not to mention the finger pointing at the originator! But one advantage the author of a New Yorker article is "the comfortable knowledge that the fact-checking department is going to follow up behind me." With regards to writing technical articles and books, while we may have the assistance of tech reviewers, what I dread is anything I missed being caught by a reader! Of course, the same applies to the software we build and happily many developers have minions of QA Testers following up behind them. And of course there's unit testing. But more often than not, our end users end up discovering something that slipped through the cracks. I have had apps in production for years when suddenly a new employee comes along and performs a task a bit differently than anyone ever did before and uncovers a bug that has been hiding in wait for so long. So, if you want a chance to step back and get a good laugh at our predicament, I'd recommend blocking out some of your XBOX time to read McPhee's article. Uh oh. It's the old bait and switch! Unfortunately I just discovered that the magazine has changed its online access policy. So you might want to stop by your local newsstand or library if you aren't a subscriber. |

