5 ms·

I agree it's better to just ask, but whenever I catch myself asking to ask, it's not due to laziness but rather to (perhaps misguided) politeness. Sometimes it

I agree it's better to just ask, but whenever I catch myself asking to ask, it's not due to laziness but rather to (perhaps misguided) politeness. Sometimes it feels a little abrupt to dm someone or bust into a team channel and just start asking questions (though perhaps that's irrational since it never bothers me when the roles are reversed). I think the site would be a little better if it addressed this motivation too.

xwdv 6y ago
It is better to be efficient than polite. Better to be predictable than "nice".
- msla 6y ago
  > It is better to be efficient than polite. Better to be predictable than "nice". At work, efficiency is polite and predictability is nice. Watercooler talk excepted, of course, and my company has a couple "watercooler" Slack channels.
- JadeNB 6y ago
  > It is better to be efficient than polite. Better to be predictable than "nice". I probably agree on the second, but I think the first is subject to what the definition of 'better' is. If someone has to give me, say, a bad evaluation of my performance, then the most efficient way for them to do it is to walk up, say "terrible performance" (and possibly list reasons), and leave—but I certainly don't feel, as the recipient of the news, that that is the best way for it to be delivered.
  - xwdv 6y ago
    Sure it is, after being given a comprehensive explanation about your terrible performance, you will have no doubts about what needs to be fixed.
    - JadeNB 6y ago
      A comprehensive explanation is less efficient than a cursory explanation.
      - Ace17 6y ago
        Efficient doesn't mean "fast". It means that it minimizes the ratio "energy_spent / goal". So if we're going to talk about communication efficiency, we need to define what's the goal being optimized here. If a manager wants to minimize the time spent dealing with one of the engineers and wants to see this engineer quit, then the "cursory explanation" can be considered "efficient". If this same manager, instead, wants to maximizes the odds the engineer stays and improves her/his weak points, then the "comprehensive" explanation might be a lot more efficient, despite requiring the manager to spend more time at it.
- Ace17 6y ago
  Communication inefficiency wastes your interlocutor's time. Depending on the context, it might be considered rude.
gouggoug 6y ago
It's all about how you ask. Simply saying: "Good morning everyone, would anybody be available to answer a question? I am running into [describe your problem]. Thank you.". Easy, polite and to the point.
- tobr 6y ago
  That looks nice, but often the [describe your problem] part is three paragraphs and a few code snippets.
  - rcfox 6y ago
    You can interrupt my channels with a three paragraph problem description any time. I'll gladly take that over "the thing doesn't work."
  - jgwil2 6y ago
    Put "Good morning everyone, would anybody be available to answer a question?" in the channel, then reply to it in a thread with the details.
    - Ace17 6y ago
      Wouldn't this approach exactly have the issues the article recommends against?
      - jgwil2 6y ago
        Type out the question in full in a text editor, then paste it after the greeting if you're worried about delay. Although if you're posting in a channel, I don't even think it's an issue; people will see that you are typing and follow up when you have provided more info.
  - ajford 6y ago
    At my current employer, the common pattern is a TLDR of the problem as the initiator, then thread your more elaborate description. Though we also usually have private team channels and separate support channels for a team in our Slack. I.e. the SRE team might have their own sre-priv channel for team chatter, and an sre-support channel for external support requests, so perhaps that is a function of this format. You'll often see a new msg in the support chan with something like the following: > Hey #TEAM, we're seeing an issue with the spline reticulator not reticulating splines. Started last night. Details in :thread:. Thanks! followed by notes/logs/stack traces as needed. Works quite well, and doesn't choke the channel with endless walls of text.
deleted 6y ago
[deleted]

xwdv 6y ago

It is better to be efficient than polite. Better to be predictable than "nice".

msla 6y ago
> It is better to be efficient than polite. Better to be predictable than "nice". At work, efficiency is polite and predictability is nice. Watercooler talk excepted, of course, and my company has a couple "watercooler" Slack channels.
JadeNB 6y ago
> It is better to be efficient than polite. Better to be predictable than "nice". I probably agree on the second, but I think the first is subject to what the definition of 'better' is. If someone has to give me, say, a bad evaluation of my performance, then the most efficient way for them to do it is to walk up, say "terrible performance" (and possibly list reasons), and leave—but I certainly don't feel, as the recipient of the news, that that is the best way for it to be delivered.
- xwdv 6y ago
  Sure it is, after being given a comprehensive explanation about your terrible performance, you will have no doubts about what needs to be fixed.
  - JadeNB 6y ago
    A comprehensive explanation is less efficient than a cursory explanation.
    - Ace17 6y ago
      Efficient doesn't mean "fast". It means that it minimizes the ratio "energy_spent / goal". So if we're going to talk about communication efficiency, we need to define what's the goal being optimized here. If a manager wants to minimize the time spent dealing with one of the engineers and wants to see this engineer quit, then the "cursory explanation" can be considered "efficient". If this same manager, instead, wants to maximizes the odds the engineer stays and improves her/his weak points, then the "comprehensive" explanation might be a lot more efficient, despite requiring the manager to spend more time at it.
Ace17 6y ago
Communication inefficiency wastes your interlocutor's time. Depending on the context, it might be considered rude.

gouggoug 6y ago

It's all about how you ask. Simply saying: "Good morning everyone, would anybody be available to answer a question? I am running into [describe your problem]. Thank you.". Easy, polite and to the point.

tobr 6y ago
That looks nice, but often the [describe your problem] part is three paragraphs and a few code snippets.
- rcfox 6y ago
  You can interrupt my channels with a three paragraph problem description any time. I'll gladly take that over "the thing doesn't work."
- jgwil2 6y ago
  Put "Good morning everyone, would anybody be available to answer a question?" in the channel, then reply to it in a thread with the details.
  - Ace17 6y ago
    Wouldn't this approach exactly have the issues the article recommends against?
    - jgwil2 6y ago
      Type out the question in full in a text editor, then paste it after the greeting if you're worried about delay. Although if you're posting in a channel, I don't even think it's an issue; people will see that you are typing and follow up when you have provided more info.
- ajford 6y ago
  At my current employer, the common pattern is a TLDR of the problem as the initiator, then thread your more elaborate description. Though we also usually have private team channels and separate support channels for a team in our Slack. I.e. the SRE team might have their own sre-priv channel for team chatter, and an sre-support channel for external support requests, so perhaps that is a function of this format. You'll often see a new msg in the support chan with something like the following: > Hey #TEAM, we're seeing an issue with the spline reticulator not reticulating splines. Started last night. Details in :thread:. Thanks! followed by notes/logs/stack traces as needed. Works quite well, and doesn't choke the channel with endless walls of text.

deleted 6y ago

[deleted]