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.
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.
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.
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
“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.
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.
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.
> 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.
> 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."
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
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".
I find it funny that the post promotes stripping useless information and yet a ton of the most useful information in those examples is placed in the skippable part.
Your coworkers are under too high a load, documentation is faulty, chain of communication is breaking down, your coworker lacks expertise in something.
All of those are calls to action!!
And no, you can’t tell the other person to “just communicate if it’s actionable” because they might not realise it. There’s lack of seniority, there’s tunnel vision…
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.
91 comments
[ 4.7 ms ] story [ 56.7 ms ] threadContext 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.
> 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.
A proper balance of direct and indirect is the appropriate tack to take.
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.
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!
This reminds me of when my kids declare "I'M HUNGRY". Cool story bro, I'll record it in my journal.
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."
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".
Your coworkers are under too high a load, documentation is faulty, chain of communication is breaking down, your coworker lacks expertise in something.
All of those are calls to action!!
And no, you can’t tell the other person to “just communicate if it’s actionable” because they might not realise it. There’s lack of seniority, there’s tunnel vision…
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.