Discussion

¶

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.

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.

dennis_jeeves2: >considerably worse place if everyone abided by such rulesThose rules are not meant for everyone.

d-us-vb: The blog post is an open letter: the author wants everyone reading to follow the those rules.

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.

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.

altairprime: [delayed]

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

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

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.

chuckadams: slow clap

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.

chuckadams: I'm a big fan of getting to the point and not belaboring, and I like when others do the same with me. That said, I tend to prefer that someone types at me in a cold open like they might speak to me, and that involves a ceremonial "Hi, how's it going?" on occasion, not just rattling out status updates and reports. Sure there are annoyingly ingratiating people out there, but if a majority of people annoy you with their pleasantries, it's very much a you problem.The irony now of course is that it's the robots that are the most unctuous thanks to their attempts to not sound robotic.

Smaug123: No. Crocker's rules are a request for people to act a certain way with respect to you, not wrt anyone else.

dolebirchwood: The irony of your comment's tone is overwhelming.

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

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!

andrewflnr: 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 short 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.

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.

andrewflnr: Yes, in particular emotional trust is key. Maybe a few people can just declare their own emotional reactions away and have that stick, but you can't ask that of other people. We're still just apes. So if you want brief, clear communication, you need people to actually believe in their guts that when you tell them something they did is broken, it's not a personal attack.

wnoise: Because those are far more general than what he is asking for, and what he is asking for will usually not be seen as covered by your generalization.

wizzwizz4: 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:> 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.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/.

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

lr0: I would have written a shorter letter, but I did not have the time.

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.

analognoise: Thought I’d try maximally direct communication.

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

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

sgarland: Being direct isn’t being an asshole. Sprinkling random compliments and self-deprecating comments into useful feedback in a professional environment is disrespectful of time.I’m convinced that the root cause is people are afraid to be wrong. Either they’re fearful of being fired, or think people will respect them less if they admit not knowing; the result is that everyone dances around objectivity.I don’t care if you make an honest mistake. Hell, I don’t even care if you make a careless mistake, as long as you fix yourself. Everyone messes up - it’s how you act afterwards that matters.

1970-01-01: This sounds absolutely perfect for interaction with an LLM. It should be a toggle switch in settings.

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).

groby_b: > 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.

tmoertel: I agree with the sentiment that gratuitous happy-talk adds noise to what ought to be clear, bottom-line-up-front engineering communications. But the recipients of those communications are people, and most people have feelings. So a good engineer ought to optimize those communications for overall success, and that means treating the intended recipients as if they matter. Some human-level communication is usually beneficial.So, to use an example from the original post:> "I hope this is okay to bring up and sorry for the long message, I just wanted to flag that I've been looking at the latency numbers and I'm not totally sure but it seems like there might be an issue with the caching layer?There’s a lot of noise in this message. It’s noise because it doesn’t communicate useful engineering information, nor does it show you actually care about the recipients.Here’s the original post’s suggested rewrite:> The caching layer is causing a 400ms overhead on cold requests. Here's the trace.This version communicates some of the essential engineering information, but it loses the important information about uncertainty in the diagnosis. It also lacks any useful human-to-human information.I’d suggest something like this:> Heads up: It looks like the caching layer is causing a 400ms overhead on cold requests. Here's the trace. Let me know how I can help. Thanks!My changes are in italics. Breaking them down:“Heads up” provides engineering context and human-to-human information: You are trying to help the recipients by alerting them to something they care about.“It looks like” concisely signals that you have a good faith belief in your diagnosis but are not certain.“Let me know how I can help” makes clear that you share the recipients’ interest in solving the problem and are not just dumping it at their feet and turning your back on them. You and they are on the same team.“Thanks!” shows your sincere appreciation to the recipients for looking into the issue. It’s a tiny contribution of emotional fuel from you to them to give them a boost after receiving what might be disappointing news.In sum, strip the noise and concisely communicate what is important, both engineering information and human information.