Live data from Hacker News

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

lr0.org

1–10 of 335 posts

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

#3

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.

>considerably worse place if everyone abided by such rules

Those rules are not meant for everyone.

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

#4
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.

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

#7

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.

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.

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

#9
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.

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

#10
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
Post reply on HN