I beg you to follow Crocker's Rules, even if you will be rude to me
1–10 of 335 posts
Re: I beg you to follow Crocker's Rules, even if you will be rude to me
#2Re: I beg you to follow Crocker's Rules, even if you will be rude to me
#3This 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.
Those rules are not meant for everyone.
Re: I beg you to follow Crocker's Rules, even if you will be rude to me
#4Context 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
#5Re: I beg you to follow Crocker's Rules, even if you will be rude to me
#6Re: I beg you to follow Crocker's Rules, even if you will be rude to me
#7You 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
#8Re: I beg you to follow Crocker's Rules, even if you will be rude to me
#9> 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.