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.
> 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.
> 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'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".
> 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!
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.
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.
I agree with your point about human level communication and treating the recipients like they matter. I generally tend to prefer communication that is more on the blunt/direct side, but if there's one thing about communication that I've learned throughout my career, it is that the people who do best are adept at communicating well with a wide variety of people with different communication styles and preferences.
The people who try to force everyone else to fit into a specific bucket of communication style, or who refuse to deviate from their own strict communication preferences no matter the audience, those are the people I see struggle to find success relative to their peers.
"seems to be causing" is also an excellent alternative to "it looks like" that doesn't hinge on visual-sensory primacy, and tends to translate slightly less ambiguously across language-familiarity boundaries due to 'seems' having more precise meaning re: uncertainty than 'looks', 'feels', 'sounds'. Or you could abbreviate to "could be" (low likelihood), "may be" (medium likelihood), "is probably" (high likelihood) if that sort of nuance is your thing.
"Let me know how I can help" should not be taken for granted as a thing to be offered, though. Some teams have very strict divisions of labor. Some workers (especially anyone whose duties are 'monitor and report' rather than 'creatively solve') are not overtime-exempt and cannot volunteer their time. Some workers (especially anyone who's reached a high-capability tech position from the ground up) are flooded with opportunities to do less of their own job and more of everyone else's and must not preemptively offer their time to an open-ended offer of 'help'. A more focused phrase such as "Let me know if you have questions, need more evidence, etc." provides a layer of defense against that without implicitly denying assistance for help if requested.
"Thanks!" is one of the most mocked request-terminators I've seen in twenty years of business. It is widely abused as "have fun storming the castle, i'm out micdrop" rather than as a sincere expression of gratitude that contains any actual statement of why you're grateful. "Thank you for doing the job the company paid you to do" sounds ridiculous when you say it out loud, even to neurotypicals. Tell people thank you with more than one word if you mean it, and tell them what you're thanking them for, and consider thanking them for what they did rather than lobbing it like a grenade strapped to a problem. If you hand them a problem and they say "got it, I'll look into it", saying "Thanks." to that is completely fine; it serves the exact purpose of courtesy described, and also doubles as a positive-handoff "your plane" reply concluding the problem handoff, so that you can safely mark it as delegated, they can safely assume you didn't miss their message and are continuing to work it, etc.
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.
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…
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.
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 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
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.
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.
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.
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?
> 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.
reply