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.
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.
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/. Nancy G. Leveson's CAST Handbook is perhaps most directly applicable.
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
> 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."
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.
Some people have an attitude to work resembling “I spend most of my day here, so having enjoyable professional relationships with my coworkers is a major determinant of my quality of life.” And there are other people who have an attitude closer to “it’s my goal to deliver value efficiently and get paid. I’m not here to make friends. Any meaningful human interactions happen outside of work.”
I don’t know enough about autism to know if that’s the right label for the second category. (I’ve had coworkers who identified as autistic who seemed to deeply care about whether I enjoyed working with them.) I think these two types of people can work together productively, but I don’t think they’ll ever totally understand each other.
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.
> 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!
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.
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.
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.
I don’t agree - the type of communication between certain members makes a team harder for everyone to join. You end up with tribal knowledge to the extreme if you communicate like this. It’s why it is unbelievably bad advice - it claims it respects a listener’s time yet creates an environment where the majority won’t listen.
> You end up with tribal knowledge to the extreme if you communicate like this.
Wait, what? How does a team habit of bluntly stating facts result in "tribal knowledge"? If anything it should be the opposite. The approach in the article has problems but I don't believe that's one of them.
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.
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
Your comment declares your opinion without explanation, and so lacks substance and is unpersuasive as written. More information would help HN readers evaluate your claims fairly rather than dismiss you. In specific, I’d love to hear your views on these questions so I can give you serious consideration:
> This is a recipe for disaster.
What about Crocker’s Rules, and/or this post’s advice to follow them, do you consider a recipe for disaster?
> Please don’t follow Crocker’s Rules;
What outcome are you hoping will result from granting your request? Do you have personal experiences with Crocker’s Rules underpinning this advice? Do you tend to experience social discomfort typically, atypically, or infrequently / never?
> just get better at communicating than the person who wrote this
Other than the presumed adherence to Crocker’s Rules in writing this, which is addressed by the questions above, do you have other criticisms of their writing to present? What communication ideals do you consider as better models than Crocker’s Rules? Do you consider there to exist appropriate circumstances for Crocker’s Rules?
“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.
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.
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.
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/. Nancy G. Leveson's CAST Handbook is perhaps most directly applicable.
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
> 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."
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.
Some people have an attitude to work resembling “I spend most of my day here, so having enjoyable professional relationships with my coworkers is a major determinant of my quality of life.” And there are other people who have an attitude closer to “it’s my goal to deliver value efficiently and get paid. I’m not here to make friends. Any meaningful human interactions happen outside of work.”
I don’t know enough about autism to know if that’s the right label for the second category. (I’ve had coworkers who identified as autistic who seemed to deeply care about whether I enjoyed working with them.) I think these two types of people can work together productively, but I don’t think they’ll ever totally understand each other.
>considerably worse place if everyone abided by such rules
Those rules are not meant for everyone.
The blog post is an open letter: the author wants everyone reading to follow the those rules.
No. Crocker's rules are a request for people to act a certain way with respect to you, not wrt anyone else.
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.
> 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!
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.
Maybe this is a bit US-centric, direct negative feedback is very common in many cultures, e.g. Dutch
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.
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.
I don’t agree - the type of communication between certain members makes a team harder for everyone to join. You end up with tribal knowledge to the extreme if you communicate like this. It’s why it is unbelievably bad advice - it claims it respects a listener’s time yet creates an environment where the majority won’t listen.
> You end up with tribal knowledge to the extreme if you communicate like this.
Wait, what? How does a team habit of bluntly stating facts result in "tribal knowledge"? If anything it should be the opposite. The approach in the article has problems but I don't believe that's one of them.
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.
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.
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
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.
This article spends a lot of words to tell us that we should be more succinct in our communication.
I would have written a shorter letter, but I did not have the time
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
> "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.
This is a recipe for disaster. Please don’t follow Crocker’s Rules; just get better at communicating than the person who wrote this.
Your comment declares your opinion without explanation, and so lacks substance and is unpersuasive as written. More information would help HN readers evaluate your claims fairly rather than dismiss you. In specific, I’d love to hear your views on these questions so I can give you serious consideration:
> This is a recipe for disaster.
What about Crocker’s Rules, and/or this post’s advice to follow them, do you consider a recipe for disaster?
> Please don’t follow Crocker’s Rules;
What outcome are you hoping will result from granting your request? Do you have personal experiences with Crocker’s Rules underpinning this advice? Do you tend to experience social discomfort typically, atypically, or infrequently / never?
> just get better at communicating than the person who wrote this
Other than the presumed adherence to Crocker’s Rules in writing this, which is addressed by the questions above, do you have other criticisms of their writing to present? What communication ideals do you consider as better models than Crocker’s Rules? Do you consider there to exist appropriate circumstances for Crocker’s Rules?
“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.
The irony of your comment's tone is overwhelming.
Thought I’d try maximally direct communication.