I beg you to follow Crocker's Rules, even if you will be rude to me

There is a concept called Crocker's Rules, and if you have never heard of it, the short version is this: you give people around you explicit permission to be maximally direct with you, to skip social cushioning. The person invoking Crocker's Rules is saying, in effect, "your feelings about how I might receive this are your problem to manage, not mine, just give me the information."

A person receiving a message bears full responsibility for their own emotional reaction to its content. If someone tells you your code is wrong, your emotional response to that is your problem to manage, not theirs to preemptively defuse. And no this is not a way to get away with cruelty nor an invitation to insult people it is just a mutual agreement that both parties are here to exchange information efficiently, and neither party is going to spend calories on social theater that adds zero signal.

What it means in practice is that your colleague can write "this approach is wrong, here's why" instead of "hey, hope you're doing well, I had some time to look at your PR and I just wanted to shared a few small thoughts, please take these as just one perspective, and of course you know the codebase better than I do, but I was wondering if maybe we could potentially consider…" and then bury the actual point six paragraphs deep. Both messages contain the same information. Only one of them respects your time.

The Slack message that starts with "Hey! Hope you had a great weekend :)" before asking a technical question or the PR comment that opens with "I'm not sure if I'm missing something here and sorry if this is a dumb question but…" before raising a completely valid concern (see also nohello.com), or a hell of an incident text that spends two full paragraphs explaining that the author was sleep-= deprived and had a lot on their plate and the monitoring tool had a weird quirk that they didn't know about and their lead had told them something ambiguous three weeks ago, before finally getting around to saying what actually broke and why. This is the literal opposite of professionalism and my personal sense of it is anxiety cosplaying as politeness.

I personally value being direct, so anyone who talks in this way with me usually make their position worse to me, even subconsciously, but I can argue that this happens too to everyone even to those who are not aware of the Crocker's Rules or do not even care about it. When you spend the first third of your message establishing that you are a nice person who means well, you are not being considerate but you are making the recipient wade through noise to get to signal. You are training them to skim your messages, which means that when you actually need them to read carefully, they might not. You are demonstrating that you do not trust the relationship enough to just say the thing, you are signaling a level of insecurity that undermines the technical credibility you are trying to establish. Nobody reads "hope you had a great weekend" and thinks better of the person who wrote it. They probably just being trained to take you less seriously in the future, or at worse, if they're evil loving to Crocker's like myself, they just think about the four seconds of their life they will never get back.

Another thing that I find it worse is apologizing preemptively, this is the behavior where someone, when something goes wrong or when they need to explain a decision, does not just explain the decision. They explain why they made the decision, and then explain the contextual factors that influenced that, and then explain why those contextual factors existed, and then explain why it would have been unreasonable to expect them to anticipate the downstream effect of those factors, and by the end you have a five-paragraph essay that contains maybe one sentence worth of information and reads like a legal defense brief written by someone who knows they are guilty.

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. Ok?

The fact that you were stressed, or that you had inherited the config from someone else, or that the documentation was unclear¹, 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. But confessing your emotional state and your reasoning process and your extenuating circumstances is not documentation, it is self-absolution and everyone reading it can tell the difference.

More importantly: it wastes their time and it buries the information they actually need to act on.