Comment by dantillberg

Writing stories for a technical audience is tricky. I've been doing it for going on 10 years now, and I'm still not very good at it.

A critical rule, however, is to omit detail, (a reader is unlikely to question an explanation they make up themselves) and most importantly, to omit details you know to be wrong. (It is impossible to nitpick a statement that is never said)

  An odd feature of our campus network at the time was that it was 100%
  switched.  An outgoing packet wouldn't incur a router delay until hitting
  the POP and reaching a router on the far side.  So time to connect to a
  lightly-loaded remote host on a nearby network would actually largely be
  governed by the speed of light distance to the destination rather than by
  incidental router delays.

He knew this was largely wrong, and didn't really improve the story, yet he said it anyway. It should have been summarized in a single sentence, leaving out all the problematic assertions that the slashdot trolls leaped on.

Yes, I found this to be one of the most refreshing technical anecdotes I've ever read. The tone and style actually put a smile on my face as I read. I enjoyed how the author guided us through the process of discovery, one which we all know so well, driven by an insatiable curiosity to go continually deeper down the rabbit hole until we find the bottom.

Thanks.

In Real Life, I totally agree the details are important. And I think I have evidence of this: at Google, where they had peer bonuses where one engineer could give money to another as a pat-on-the-back, I got dozens for my post-mortems.

Post-mortems are a case where you must have both story and correct details: lack the first, and you won't create change because the people who need to know in order to implement the required recommendations won't read the whole thing (or retain it later); lack the second, and really, how can anyone trust your recommendations?

Here, I was just trying to quickly bang out a funny anecdote. The things that stuck in my mind I could use to reverse-engineer numbers. I did this because—at the time I worked the incident—I was working with real numbers, so the story needed them for verisimilitude, to give a sense of what I was wrestling with. If I'd had any clue this mail would have taken on such a life of its own, I would have been more careful with them and gotten a tech reviewer and copy editor before posting.

This gets posted on some forum or another several times a year; for a long time I had a Google Alert on it and would hop in threads whenever it happened, since it always followed a common pattern:

1. Someone posts a link to the story, but not my canonical copy with a link to the FAQ.

2. More trusting and/or less-technical respondents upvote or forward or Like or +1 or quasisuperplauditize or whatever the medium has until it gets notice from...

3 ... less trusting and/or more-technical types, who expose the "flaws", most of which are covered in the FAQ.

4. Someone thinks to do a Google on "500 mile email", which returns as the top two results my canonical copy and the FAQ, and posts a link.

5. Most people lose interest while a few continue to squabble over ever-finer details.

Depending on at what point I jumped in, I could affect the speed of the above cycle, but it never changed the cycle itself. The fun of the story is following me through my own emotional cycle I felt when I worked the issue, starting with the initial "no way" to "you're having me on, right?" to "maybe...", to "dear God, this is actually happening", to "I must be going crazy", and finally to "Eureka!"

My intervention in the above cycle really wasn't adding that much to the enjoyment of the story, so I stopped doing it. (I'm not sure it's adding anything today, either, but Hacker News is an important enough forum for people I respect and care about that I thought I'd break vow and rejoin the fray this once.)