4 ms·

Some of those examples are genuinely different as they convey different intent and certainty. Also some of the basic small talk level things are also there to g

by IanCal 7mo ago

Some of those examples are genuinely different as they convey different intent and certainty. Also some of the basic small talk level things are also there to gauge someone’s responsiveness right now. To ask directly can mean “I believe my issue is important enough to immediately change what you’re thinking about to my problem without checking first”. You might complain about breaking your flow, which is fine, but an interruption can be a lot less disruptive compared to getting nerd sniped. > Both messages contain the same information, however one of them respects time. Unless you’re an incredibly slow reader this is a tiny amount of time. > The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear3, or that you asked your lead and they said it was probably fine, none of that is relevant to the incident report. You can document contributing factors if they are actually actionable, meaning if there is something structural that needs to change, name it specifically and attach a proposed fix to it. Those are absolutely relevant! A lead told you to do it? Documentation unclear? One stressed person unable to hand over the task? And you don’t have to have a solution there to highlight a problem. > If the payment service went down because a config value was wrong, the incident report should say: the payment service went down because config value X was set to Y when it needed to be set to Z. Contains zero useful information as to how this happened. It’d be like saying you don’t want to know what the user did before the crash, just that it crashed but shouldn’t have done because it got into invalid state X.

andrewflnr 7mo ago
Yeah, skip the fluff about my having a good weekend if you need me to fix something, but a lot of those uncertainty markers aren't fluff, they're essential to honest, accurate communication. Similarly, many times when you say a variation on "I know you're the expert on the codebase" or whatever, that's because it's true and important. Something I think is a problem, which this article wants me to phrase as a short, plain declaration, might actually just be a misunderstanding on my part. If I get one of those messages, I'm not going to see my time being respected. I'm going to see an arrogant jerk too lazy to learn what they're talking about before shooting off their mouth.
- wizzwizz4 7mo ago
  And as a writer: I find that my instinct to write caveats like "I know you're the expert on the codebase" corresponds to a process I need to follow to verify the information. Emails like this can take me hours to write, as I scour the codebase, logs, etc for the missing pieces of information demanded by "mere politeness". Here's an example of a reply I got: > Thank you for your careful report, I will attend to it asap. The response was short and to the point, because no other information was relevant. And, indeed, I have written emails like that in the past. But, from the article: > The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear3, or that you asked your lead and they said it was probably fine, none of that is relevant to the incident report. Those things are often all relevant. I beg the author to read a book about system-theoretic process analysis (STPA). Some are freely-available from the MIT PSASS website: https://psas.scripts.mit.edu/home/books-and-handbooks/ https://psas.scripts.mit.edu/home/books-and-handbooks/. Nancy G. Leveson's CAST Handbook is perhaps most directly applicable.
- duskdozer 7mo ago
  It's also a misinterpretation of the "nohello", which is about dragging things out over multiple messages and time to put the actual message. Just adding some pleasantries at the beginning isn't the same thing.
  - dpark 7mo ago
    Right. Nohello isn't about not saying hello. It's about not sending a message with nothing but a greeting and leaving the recipient waiting to find out what you want. It's about being efficient and respectful of the recipient's time. If you're so pathologically "efficient" that you are bothered by reading the word "Hello" in "Hello. Please join the bridge. The site is down.", that's a you problem, not a hello problem.
- throw10920 7mo ago
  > a lot of those uncertainty markers aren't fluff, they're essential to honest, accurate communication. > Similarly, many times when you say a variation on "I know you're the expert on the codebase" or whatever, that's because it's true and important. Something I think is a problem, which this article wants me to phrase as a short, plain declaration, might actually just be a misunderstanding on my part. This is not what the article says. The author is not advocating for removal of relevant information (including uncertainty markers and that which you describe as "true and important") - only information that is not relevant, such as "I'm not sure if I'm missing something here and sorry if this is a dumb question but" that is an example in the post. And, if the information may be relevant, the author would ask you to include it - concisely, without fluff. The main thing that Crocker's Rules are trying to cut out (in a LIMITED SPECIFIC OPT-IN BASIS) is specifically irrelevant information due to social graces/fear of offense. If it could be useful, the author (and Crocker) would have you include it.
groby_b 7mo ago
> but an interruption can be a lot less disruptive compared to getting nerd sniped. Theoretically yes. Practically, folks who avoid small talk deliberately usually have enough awareness to not interrupt unless they need your time. But yes, directness without judgment is bad. Ironically, the author fails to apply that judgment themselves and wastes a ton of words on unnecessary and/or bad examples. And, more importantly, they miss the core point of Crocker's rule: Invoking it doesn't mean you get to tell other people how to communicate. You just tell them they're not responsible for your emotional/mental state. If those extra details upset OP, maybe they lack the maturity to invoke that rule.
- IanCal 7mo ago
  > Practically, folks who avoid small talk deliberately usually have enough awareness to not interrupt unless they need your time. It’s not whether you need my time it’s where it falls in my priorities which you do not know. By essentially not asking they will get it wrong more, in both directions.
  - groby_b 7mo ago
    Sure. And so it depends on how many people you need to talk to on a daily basis, and how often the interruption is worth your time. It's recall vs. precision in an org-shaped trenchcoat.

by IanCal 7mo ago

andrewflnr 7mo ago

Yeah, skip the fluff about my having a good weekend if you need me to fix something, but a lot of those uncertainty markers aren't fluff, they're essential to honest, accurate communication. Similarly, many times when you say a variation on "I know you're the expert on the codebase" or whatever, that's because it's true and important. Something I think is a problem, which this article wants me to phrase as a short, plain declaration, might actually just be a misunderstanding on my part. If I get one of those messages, I'm not going to see my time being respected. I'm going to see an arrogant jerk too lazy to learn what they're talking about before shooting off their mouth.

wizzwizz4 7mo ago
And as a writer: I find that my instinct to write caveats like "I know you're the expert on the codebase" corresponds to a process I need to follow to verify the information. Emails like this can take me hours to write, as I scour the codebase, logs, etc for the missing pieces of information demanded by "mere politeness". Here's an example of a reply I got: > Thank you for your careful report, I will attend to it asap. The response was short and to the point, because no other information was relevant. And, indeed, I have written emails like that in the past. But, from the article: > The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear3, or that you asked your lead and they said it was probably fine, none of that is relevant to the incident report. Those things are often all relevant. I beg the author to read a book about system-theoretic process analysis (STPA). Some are freely-available from the MIT PSASS website: https://psas.scripts.mit.edu/home/books-and-handbooks/ https://psas.scripts.mit.edu/home/books-and-handbooks/. Nancy G. Leveson's CAST Handbook is perhaps most directly applicable.
duskdozer 7mo ago
It's also a misinterpretation of the "nohello", which is about dragging things out over multiple messages and time to put the actual message. Just adding some pleasantries at the beginning isn't the same thing.
- dpark 7mo ago
  Right. Nohello isn't about not saying hello. It's about not sending a message with nothing but a greeting and leaving the recipient waiting to find out what you want. It's about being efficient and respectful of the recipient's time. If you're so pathologically "efficient" that you are bothered by reading the word "Hello" in "Hello. Please join the bridge. The site is down.", that's a you problem, not a hello problem.
throw10920 7mo ago
> a lot of those uncertainty markers aren't fluff, they're essential to honest, accurate communication. > Similarly, many times when you say a variation on "I know you're the expert on the codebase" or whatever, that's because it's true and important. Something I think is a problem, which this article wants me to phrase as a short, plain declaration, might actually just be a misunderstanding on my part. This is not what the article says. The author is not advocating for removal of relevant information (including uncertainty markers and that which you describe as "true and important") - only information that is not relevant, such as "I'm not sure if I'm missing something here and sorry if this is a dumb question but" that is an example in the post. And, if the information may be relevant, the author would ask you to include it - concisely, without fluff. The main thing that Crocker's Rules are trying to cut out (in a LIMITED SPECIFIC OPT-IN BASIS) is specifically irrelevant information due to social graces/fear of offense. If it could be useful, the author (and Crocker) would have you include it.

groby_b 7mo ago

> but an interruption can be a lot less disruptive compared to getting nerd sniped. Theoretically yes. Practically, folks who avoid small talk deliberately usually have enough awareness to not interrupt unless they need your time. But yes, directness without judgment is bad. Ironically, the author fails to apply that judgment themselves and wastes a ton of words on unnecessary and/or bad examples. And, more importantly, they miss the core point of Crocker's rule: Invoking it doesn't mean you get to tell other people how to communicate. You just tell them they're not responsible for your emotional/mental state. If those extra details upset OP, maybe they lack the maturity to invoke that rule.

IanCal 7mo ago
> Practically, folks who avoid small talk deliberately usually have enough awareness to not interrupt unless they need your time. It’s not whether you need my time it’s where it falls in my priorities which you do not know. By essentially not asking they will get it wrong more, in both directions.
- groby_b 7mo ago
  Sure. And so it depends on how many people you need to talk to on a daily basis, and how often the interruption is worth your time. It's recall vs. precision in an org-shaped trenchcoat.