logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

A-philosophy-for-instant-messaging.md (6469B)


  1. ---
  2. title: My philosophy for productive instant messaging
  3. date: 2021-11-24
  4. outputs: [html, gemtext]
  5. ---
  6. We use Internet Relay Chat ([IRC][0]) extensively at [sourcehut][1] for
  7. real-time group chats and one-on-one messaging. The IRC protocol is quite
  8. familiar to hackers, who have been using it since the late 80's. As chat rooms
  9. have become more and more popular among teams of both hackers and non-hackers in
  10. recent years, I would like to offer a few bites of greybeard wisdom to those
  11. trying to figure out how to effectively use instant messaging for their own
  12. work.
  13. [0]: https://en.wikipedia.org/wiki/Internet_Relay_Chat
  14. [1]: https://sourcehut.org
  15. For me, IRC is a vital communication tool, but many users of <insert current
  16. instant messaging software fad here>[^1] find it frustrating, often to the
  17. point of resenting the fact that they have to use it at all. Endlessly catching
  18. up on discussions they missed, having their workflow interrupted by unexpected
  19. messages, searching for important information sequestered away in a discussion
  20. which happened weeks ago... it can be overwhelming and ultimately reduce your
  21. productivity and well-being. Why does it work for me, but not for them? To find
  22. out, let me explain how I think about and use IRC.
  23. [^1]: 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.
  24. The most important trait to consider when using IM software is that it is
  25. *ephemeral*, and must be treated as such. You should not "catch up" on
  26. discussions that you missed, and should not expect others to do so, either. Any
  27. important information from a chat room discussion must be moved to a more
  28. permanent medium, such as an email to a mailing list,[^2] a ticket filed in a
  29. bug tracker, or a page updated on a wiki. One very productive use of IRC for me
  30. is holding a discussion to hash out the details of an issue, then writing up a
  31. summary up for a mailing list thread where the matter is discussed in more
  32. depth.
  33. [^2]: Email is great. If you hate it you might be [using it wrong](https://useplaintext.email).
  34. I don't treat discussions on IRC as actionable until they are shifted to another
  35. mode of discussion. On many occasions, I have discussed an issue with someone on
  36. IRC, and once the unknowns are narrowed down and confirmed to be actionable, ask
  37. them to follow-up with an email or a bug report. If the task never leaves IRC,
  38. it also never gets done. Many invalid or duplicate tasks are filtered out by
  39. this approach, and those which do get mode-shifted often have more detail than
  40. they otherwise might, which improves the signal-to-noise ratio on my bug
  41. trackers and mailing lists.
  42. I have an extensive archive of IRC logs dating back over 10 years, tens of
  43. gigabytes of gzipped plaintext files. I reference these logs perhaps only two or
  44. three times a year, and often for silly reasons, like finding out how many swear
  45. words were used over some time frame in a specific group chat, or to win an
  46. argument about who was the first person to say "yeet" in my logs. I almost never
  47. read more than a couple dozen lines of the backlog when starting up IRC for the
  48. day.
  49. Accordingly, you should never expect anyone to be in the know for a discussion
  50. they were not present at. This also affects how I use "highlights".[^3] Whenever
  51. I highlight someone, I try to include enough context in the message so that they
  52. can understand why they were mentioned without having to dig through their logs,
  53. even if they receive the notification hours later.
  54. [^3]: IRC terminology for mentioning someone's name to get their attention. Some platforms call this "mentions".
  55. *Bad*:
  56. ```
  57. <sircmpwn> minus: ping
  58. <sircmpwn> what is the best way to frob foobars?
  59. ```
  60. *Good*:
  61. ```
  62. <sircmpwn> minus: do you know how to frob foobars?
  63. ```
  64. I will also occasionally send someone a second highlight un-pinging them if the
  65. question was resolved and their input is no longer needed. Sometimes I *will*
  66. send a vague "ping &lt;username&gt;" example when I actually want them to
  67. participate in the discussion *right now*, but if they don't answer immediately
  68. then I will usually un-ping them later.[^4]
  69. [^4]: I occasionally forget to... apologies to anyone I've annoyed by doing that.
  70. This draws attention to another trait of instant messaging: it is
  71. *asynchronous*. Not everyone is online at the same time, and we should adjust
  72. our usage of it in consideration of this. For example, when I send someone a
  73. private message, rather than expecting them to engage in a real-time dialogue
  74. with me right away, I dump everything I know about the issue for them to review
  75. and respond to in their own time. This could be hours later, when I'm not
  76. available myself!
  77. *Bad*:
  78. ```
  79. <sircmpwn> hey emersion, do you have a minute?
  80. *8 hours later*
  81. <emersion> yes?
  82. *8 hours later*
  83. <sircmpwn> what is the best way to frob foobars?
  84. *8 hours later*
  85. <emersion> did you try mongodb?
  86. ```
  87. *Good*:[^5]
  88. ```
  89. <sircmpwn> hey emersion, what's the best way to frob foobars?
  90. <sircmpwn> I thought about mongodb but they made it non-free
  91. *10 minutes later*
  92. <sircmpwn> update: considered redis, but I bet they're one bad day away from making that non-free too
  93. *8 hours later*
  94. <emersion> good question
  95. <emersion> maybe postgresql? they seem like a trustworthy bunch
  96. *8 hours later*
  97. <sircmpwn> makes sense. Thanks!
  98. ```
  99. [^5]: 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 😉
  100. This also presents us a solution to the interruptions problem: just don't answer
  101. right away, and don't expect others to. I don't have desktop or mobile
  102. notifications for IRC. I only use it when I'm sitting down at my computer, and I
  103. "pull" notifications from it instead of having it "push" them to me &mdash; that
  104. is, I glance at the client every now and then. If I'm in the middle of
  105. something, I don't read it.
  106. With these considerations in mind, IRC has been an extraordinarily useful tool
  107. for me, and maybe it can be for you, too. I'm not troubled by interruptions to
  108. my workflow. I never have to catch up on a bunch of old messages. I can
  109. communicate efficiently and effectively with my team, increasing our
  110. productivity considerably, without worrying about an added source of stress. I
  111. hope that helps!