They don't need to poll a channel, most chat applications will pop up a notification when a message appears.

What they can poll is the chat app icon, and to not be AFK in the next few minutes.

What would be the purpose of providing more context before actually asking a question?

I use IM as more informal, (AND/)OR conversations with likely back-and-forth, that may require the other person to be present to be of use.

In the case that both people are present and available in the chat at the same time, sure, it's 3 seconds. If not, that extra "hi" can add latency of hours or more. Days if schedules and availability line up badly enough.

In the delay introduced by "hi", you've created uncertainty and ambiguity for your counterpart. They have no idea whether your "hi" is the prelude to something trivial, or something important, or whether it might might be relevant to work they were about to start.

"Asking to ask" is far from the biggest communication issue in the workplace, but it is bad etiquette and a very easy behavior to correct - so why not just make the barest effort to adjust the way you communicate to better fit the medium? Save the "Hi"s and "How are you"s for synchronous communication like calls or meetings. Chat has a different set of pleasantries.

Sometimes it will go days with just that message lingering "hi, how are you?" until I reply to then after a few hours/a day I finally get what she wanted to ask. It's just annoying, I've told her I much rather receive a "hey, how are you? I need some help with X" or whatever else it is the conversation to be. It's just easier and effective async communication (we live in different timezones).

Maybe the soft return is the key here. When I ask a question via slack it’s a single carefully formatted message, while my most irritating correspondents send multiple messages to convey a single question.

Oh, and don’t paste 80k log files in a message. make it easy for me to respond

I called an australian government phone line recently, i was queued, then informed i could press 1 to register for a callback. I pressed 1. Then I was prompted to say my name, I did that. Then I hung up.

Some time later, I was indeed called back - by a robot. The robot greeted me, informed me it was calling back, and requested that I pass the phone to <my name recorded from earlier>. The robot then queued me and prompted me to press 1 when <my name recorded from earlier> was on the line. Since that was me, I pressed 1. After a bit more time being queued, I was transferred to a human operator.

edit: this seems quite bemusing / irritating, but to give the designer of this callback mechanism a little more credit, it was a phone line that businesses would call -- it would not be uncommon for person A to call from a business phone line, with the callback to the company line being answered by some other person B.

It can just as well go like this:

- Bob writes "Hi" and I get a notification

- I enter the chat and wait for Bob

- 30 seconds later the indicator shows he's typing something

- 30 seconds later, still nothing

- 30 seconds later the typing indicator goes away

- I go away. Eventually Bob follows up with the actual content.

That was frustrating for me, not because of some issues I need to work with, but because Bob kept me on hold while he's trying to figure out what to say.

It's actually much more like sending someone an email that just says, "Hi!"

You'd find that weird and off-putting, wouldn't you? Not putting at least some part of the point of the conversation in the initial email completely violates the expectations for how email works.

Chat works fundamentally the same way. Yes, you can treat it as being synchronous—but until you have established an active synchronous conversation (ie, until you and the other person are clearly online at the same time, talking in real time), proper etiquette should be to treat it as asynchronous, like email, and plan one's opening communications accordingly.

That’s why it’s a shitty thing to do.

Are you ok with not having the conversation?

Async comms should regularly (and, perhaps, by default) be muted to enhance focus. Let them collect and allow the person to manage their own time. "No hello" allows them to have the question ready for them to address when they process their incoming queues.

Synchronous comms should be used to get immediate attention on an urgent issue that needs to be addressed immediately, or be used for tight, rapid iteration in a discussion (e.g. rapid design discussions). Because it necessarily takes attention away from another task, the activation energy should be higher.

It's still needless overhead. Just because interruption 13 is proportionally less painful doesn't make it free.

The one that really gets me is when a doctor's office calls me about something, but their outgoing number is different from the number I have to call to reach them, and then they start asking me authenticating questions like my DOB and address.

No, buddy. You just called me from a number I do t recognize. I'm not going to give you identifying information!

Then they offer to give me a number where I can call them back, as though that resolves the issue. I'll call you back at your published number, where I always call you, but any old scammer could give me any old number to call them back and it wouldn't make it legitimate.

I just wish they would stop training all their patients to be scam victims.

I often do this and forget to upvote correct SO answers as well. I find a solution, realize that I have to research a bunch of other things, and spawn twenty more tabs and the SO answer gets lost in the pile. What's the point of upvoting SO answers if you haven't been able to confirm that the solution is correct?

I guess I sometimes might do this with chat responses as well. But yeah in that situation something like "Thanks I will try it out!" is probably the appropriate response.

But yes, when written please, please, please just use the URL. It is at worst the same if people recognize the number, much easier if not. Plus people can quickly just check it to make sure they remembered correctly. Also shout out to ticketing software that puts the title into the URL so you get the confirmation and reminder without even clicking the link.

GitHub and GitLab are awful here. Their default merge and squash messages reference tickets with stupid short forms like #123 or other/project#123 which aren't clickable except in their web-UI. It feels like a form of lock in. I would much rather that they just put a full URL so that I can click it when reading a Git log.

Do that enough times and eventually people start to get the hint.

The whole point of this is that it is being done in an asynchronous medium, where the participants may never actually be online at the same time, but can still communicate just fine.

A question other than 'Can I ask you a quick question?' God I hate that. You mean two questions, since that was a question already. And why does it always have to be 'quick'? Does no one ever have a meaty question that will take effort to answer?

I know; I'm a crusty old fart. But boy howdy would I use that AI chatbot if it existed.

Tools also affect it. Teams is terrible for “structural”, long-lived team chats (oh, the irony!) like are totally natural in, say, Slack, so tends to push more stuff into meetings and ad-hoc group chats. It’s a really bizarre (and endlessly irritating) design choice. You also can’t “digress” within the same channel like you can in Slack without spamming the main chat.

Worse tools = people use them differently (worse) like calling more and doing more private messaging. Add corporate, division, and individual cultures and preferences, and you can get all kinds of weird stuff going on, including the bare “hello”.

But I think a lot of it is also just individual and regional foibles. Some people feel very strongly that a conversation must begin with meaningless pleasantries or it's horrifically rude. Some people feel like it's rude to just ask you a question without first asking if that's OK—even if that's your role.

We could really do with a lot more explicit communication about communication in our culture, corporate and otherwise, setting boundaries and expectations up front.

It seems that both of these problems would be solved if the sender just gets to the point?

There's no reason to add delays on both sides so people can hope they finally overlap and can have a synchronous chat. If that's what you want, just ask for a time for it in the initial message.