I disagree. I start text chats with "hello" all the time.
It basically relates to channel choice. For some kinds of messages a near-real-time text chat is the right channel but async email-like flow would be entirely the wrong channel.
So I start a convo with "hello" to probe if the other party is available for near-real-time text chat, because away-status indicators are frequently unreliable.
There are also special kinds of communication needs like if I need help with something and there are 3 people who could potentially help me out on something that's a blocker for me. I then just want to probe for the first person capable of unblocking me. The protocol is then something like: "me-to-person-a: hello". wait for 5 minutes. no respone. "me-to-person-b: hello". wait for 5 minutes. no response. "me-to-person-c: hello" wait for 5 minutes. all of a sudden person b has become available and replies "person-b-to-me: hello, what can i do for you?" ...now i start chatting with person b. meanwhile, 20 minutes after my initial prompt when I'm already well into my way, discussing my blocker with person b, person c comes online and says "hello". I respond "oh, never mind: person b is already helping me out". ...person a, as it happens, is fighting a production issue and not responding to me right now, knowing that i'm a newbie developer who likely has newbie questions. fair enough, he's entirely within his rights to ignore me.
If instead, I just open the convo with a drawn-out description of the issue i need help with, I'm kind of stuck after firing off a message to the first person. Because now, I don't want to start wasting another person's time by "cross-posting" to a second 1-on-1 chat, as that is likely to duplicate work. In that case, to be polite, I'd have to at least wait a few hours, cross-post to a second person, and then say to the first person something like "oh, it seems like you're unavailable. actually never mind, I guess person-b might be able to help me out faster". ...this latter kind of communication is kind of awkward, and in any case inefficient.
It basically relates to channel choice. For some kinds of messages a near-real-time text chat is the right channel but async email-like flow would be entirely the wrong channel.
So I start a convo with "hello" to probe if the other party is available for near-real-time text chat, because away-status indicators are frequently unreliable.
There are also special kinds of communication needs like if I need help with something and there are 3 people who could potentially help me out on something that's a blocker for me. I then just want to probe for the first person capable of unblocking me. The protocol is then something like: "me-to-person-a: hello". wait for 5 minutes. no respone. "me-to-person-b: hello". wait for 5 minutes. no response. "me-to-person-c: hello" wait for 5 minutes. all of a sudden person b has become available and replies "person-b-to-me: hello, what can i do for you?" ...now i start chatting with person b. meanwhile, 20 minutes after my initial prompt when I'm already well into my way, discussing my blocker with person b, person c comes online and says "hello". I respond "oh, never mind: person b is already helping me out". ...person a, as it happens, is fighting a production issue and not responding to me right now, knowing that i'm a newbie developer who likely has newbie questions. fair enough, he's entirely within his rights to ignore me.
If instead, I just open the convo with a drawn-out description of the issue i need help with, I'm kind of stuck after firing off a message to the first person. Because now, I don't want to start wasting another person's time by "cross-posting" to a second 1-on-1 chat, as that is likely to duplicate work. In that case, to be polite, I'd have to at least wait a few hours, cross-post to a second person, and then say to the first person something like "oh, it seems like you're unavailable. actually never mind, I guess person-b might be able to help me out faster". ...this latter kind of communication is kind of awkward, and in any case inefficient.