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

oncallthrow

This is pretty autistic. I kind of agree, being somewhat on the spectrum myself. But I think the world would be a considerably worse place if everyone abided by such rules.

camel_gopher

You can communicate like this and have it be effective if you have an established good relationship with the recipient. That’s why team cohesiveness is important. Context of whom you are communicating with is also important. That’s the trade off of approaches like these rules. In some situations they are fine. In others not so much.

hluska

This is a recipe for disaster. Please don’t follow Crocker’s Rules; just get better at communicating than the person who wrote this.

barelysapient

I'd prefer we instead all use Non-violent Communication. No need for permission. The world would be more beautiful place if we all had giraffe ears.

IanCal

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.

poszlem

I actually thought this was going to be an article about talking with an AI, i.e., something with no feelings, not about interacting with other human beings. Treating all social cushioning as useless noise is simplistic. Communication between humans is not the same as communication with a compiler. The problem is verbosity, and lack of clarity, not politness. Those are different things

anthonySs

usually the people who ask for the most direct advice are also the ones who so vehemently disagree with it when it's something they don't like

analognoise

“My quirky autism excuses me being an asshole” is how most of this reads. “Maximally direct” people need to learn how to mask better, and if it costs them too much then they’re not suited for professional work anyway.

manbitesdog

Maybe this is a bit US-centric, direct negative feedback is very common in many cultures, e.g. Dutch

Hobadee

As with everything, I think there is an appropriate middle ground here. There is definitely too much beating around the bush in a lot of professional work, but some of that is actually useful and even good. Context doesn't always matter, but sometimes it does. Manners aren't always important, but sometimes they are. A proper balance of direct and indirect is the appropriate tack to take.

d-us-vb

While I agree with the sentiment for the effect its adherents want to have, but... Why not just "Communicate clearly"? - Don't add fluff - write as plainly as possible - write as precisely as is reasonable - Only make reasonable assumptions about the reader - Do your best to anticipate ambiguity and proactively disambiguate. (Because your readers may assume that if they don't understand you, what you wrote isn't for them.) - Don't be selfish or self-centered; pay attention to the other humans because a significant amount of communication happens in nuance no matter how hard we try to minimize it.

kixiQu

> 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. The number of junior engineers I have had to coach out of this way of thinking to get the smallest fragment of value out of a postmortem process... dear Lord. I wonder if this person is similarly new to professional collaboration. The larger personal site is very aesthetically cool, though – make sure you click around if you haven't!

bcrosby95

> "The caching layer is causing a 400ms overhead on cold requests. Here's the trace." This reminds me of when my kids declare "I'M HUNGRY". Cool story bro, I'll record it in my journal.

moron4hire

This article spends a lot of words to tell us that we should be more succinct in our communication.

BiraIgnacio

There's nothing wrong in being nice and some chit-chat. Any kind of work, well most kinds of work, are about people and relationships. Building something with people when people can't relate to one another is quite hard.

treetalker

> 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." Isn't it quite the opposite? The person invoking Crocker's Rules is saying, in effect, " my feelings about the information and how I might receive it are my problem to manage, not yours , just give me the information."

TehShrike

I agree to a certain point, but I think about it in different terms – some people want to avoid any form of disagreement in order to maintain a kind of politeness, but I want to work on a team where people care enough to disagree with each other if something is wrong: https://joshduff.com/2024-07-18-communication-culture.html

mdx97

I'd say I generally agree with this sentiment, but it's important to first build the proper rapport with the recipient. If you show them kindness and respect outside the bounds of technical conversations, they'll be much more likely to assume the best of you when you communicate straight-forwardly over technical matters. You also should take care to avoid crossing the line into just being a jerk. This type of thinking is also often used by people who are simply arrogant and rude and are patting themselves on the back for being that way in the name of "directness" or "efficiency".

hyperpape

Given the subject, it is funny to me that this post is meandering and repetitive.

soupfordummies

Eh pick your battles. This doesn’t bother me nearly as much as meetings that could be emails (or worse— a couple chat messages back and forth).