š¾ Archived View for drewdevault.com āŗ 2021 āŗ 11 āŗ 24 āŗ A-philosophy-for-instant-messaging.gmi captured on 2022-04-29 at 11:01:59. Gemini links have been rewritten to link to archived content
ā¬ ļø Previous capture (2021-11-30)
-=-=-=-=-=-=-
We use Internet Relay Chat (IRC) extensively at sourcehut for real-time group chats and one-on-one messaging. The IRC protocol is quite familiar to hackers, who have been using it since the late 80ās. As chat rooms have become more and more popular among teams of both hackers and non-hackers in recent years, I would like to offer a few bites of greybeard wisdom to those trying to figure out how to effectively use instant messaging for their own work.
Internet Relay Chat on Wikipedia
For me, IRC is a vital communication tool, but many users of <insert current instant messaging software fad here>Ā¹ find it frustrating, often to the point of resenting the fact that they have to use it at all. Endlessly catching up on discussions they missed, having their workflow interrupted by unexpected messages, searching for important information sequestered away in a discussion which happened weeks agoā¦ it can be overwhelming and ultimately reduce your productivity and well-being. Why does it work for me, but not for them? To find out, let me explain how I think about and use IRC.
The most important trait to consider when using IM software is that it is ephemeral, and must be treated as such. You should not ācatch upā on discussions that you missed, and should not expect others to do so, either. Any important information from a chat room discussion must be moved to a more permanent medium, such as an email to a mailing list,Ā² a ticket filed in a bug tracker, or a page updated on a wiki. One very productive use of IRC for me is holding a discussion to hash out the details of an issue, then writing up a summary up for a mailing list thread where the matter is discussed in more depth.
I donāt treat discussions on IRC as actionable until they are shifted to another mode of discussion. On many occasions, I have discussed an issue with someone on IRC, and once the unknowns are narrowed down and confirmed to be actionable, ask them to follow-up with an email or a bug report. If the task never leaves IRC, it also never gets done. Many invalid or duplicate tasks are filtered out by this approach, and those which do get mode-shifted often have more detail than they otherwise might, which improves the signal-to-noise ratio on my bug trackers and mailing lists.
I have an extensive archive of IRC logs dating back over 10 years, tens of gigabytes of gzipped plaintext files. I reference these logs perhaps only two or three times a year, and often for silly reasons, like finding out how many swear words were used over some time frame in a specific group chat, or to win an argument about who was the first person to say āyeetā in my logs. I almost never read more than a couple dozen lines of the backlog when starting up IRC for the day.
Accordingly, you should never expect anyone to be in the know for a discussion they were not present at. This also affects how I use āhighlightsā.Ā³ Whenever I highlight someone, I try to include enough context in the message so that they can understand why they were mentioned without having to dig through their logs, even if they receive the notification hours later.
Bad:
<sircmpwn> minus: ping <sircmpwn> what is the best way to frob foobars?
Good:
<sircmpwn> minus: do you know how to frob foobars?
I will also occasionally send someone a second highlight un-pinging them if the question was resolved and their input is no longer needed. Sometimes I will send a vague āping <username>ā example when I actually want them to participate in the discussion right now, but if they donāt answer immediately then I will usually un-ping them later.ā“
This draws attention to another trait of instant messaging: it is asynchronous. Not everyone is online at the same time, and we should adjust our usage of it in consideration of this. For example, when I send someone a private message, rather than expecting them to engage in a real-time dialogue with me right away, I dump everything I know about the issue for them to review and respond to in their own time. This could be hours later, when Iām not available myself!
Bad:
<sircmpwn> hey emersion, do you have a minute?
Good:āµ
<sircmpwn> hey emersion, what's the best way to frob foobars? <sircmpwn> I thought about mongodb but they made it non-free
This also presents us a solution to the interruptions problem: just donāt answer right away, and donāt expect others to. I donāt have desktop or mobile notifications for IRC. I only use it when Iām sitting down at my computer, and I āpullā notifications from it instead of having it āpushā them to me ā that is, I glance at the client every now and then. If Iām in the middle of something, I donāt read it.
With these considerations in mind, IRC has been an extraordinarily useful tool for me, and maybe it can be for you, too. Iām not troubled by interruptions to my workflow. I never have to catch up on a bunch of old messages. I can communicate efficiently and effectively with my team, increasing our productivity considerably, without worrying about an added source of stress. I hope that helps!
Ā¹ Many, many companies have tried, and failed, to re-invent IRC, usually within a proprietary walled garden. I offer my condolences if you find yourself using one of these.
Ā² Email is great. If you hate it you might be using it wrong.ā¶
Ā³ IRC terminology for mentioning someoneās name to get their attention. Some platforms call this āmentionsā.
ā“ I occasionally forget toā¦ apologies to anyone Iāve annoyed by doing that.
āµ I have occasionally annoyed someone with this strategy. If they have desktop notifications enabled, they might see 10 notifications while I fill their message buffer with more and more details about my question. Sounds like a āyouā problem, buddy š
\ \_____ ###[==_____> /_/
āMy philosophy for productive instant messagingā was published on November 24, 2021.
View āMy philosophy for productive instant messagingā on the WWW
The content for this site is CC-BY-SA. The code for this site is MIT.