Is group chat making you sweat? (2016)
m.signalvnoise.com
m.signalvnoise.com
Thankfully it all came to a head when the buggy deploy bot made a broken deploy and we started using it just for plain chat and moved to free plan because we didn't want history on purpose.
Started probably with "Twitch Plays Pokemon", "Twich Plays/Does X" means thousands and thousands of people trying to simultaneously control a single-user game or application, with the whole thing being live-streamed.
Yeah history is actually cool, because you can forget to track, but it's too easy to say "oh it is in history search for it" ... ok./
> Sort of like forcing emacs to do everything (peace be upon emacs).
Yeah, except that people force Emacs to do everything because it's more convenient and efficient to do things this way. Things within Emacs are much more interoperable than anything else[0] in your operating system - both by having a no-bullshit, powerful[1] and consistent UI, and by being designed for interoperability and third-party extension from the get-go. Basically everything that deals mostly with text - and that includes IRC, issue tracking, e-mail, etc. - is better done in Emacs than in a standalone (or God forbid, web) tool.
Emacs OS maybe a weird and unpopular mindset, but it's a very practical mindset.
--
[0] - besides maybe terminal utilities, but we're talking applications with UI here.
[1] - all the weird shortcuts doing text magic work on everything in Emacs, so the investment pays off across everything you do within this environment.
People want their muscle memory to follow them. Emacs solved it by pulling applications into Emacs. Vim/vi "solved" it by virtue of applications adapting vim keyboard conventions. "Solved" in quotes not because it's not a solution, but because the solution wasn't implemented in Vim, but in each application where a developer wanted to use their muscle memory.
An excellent compromise solution is apps that use readline: you can use either editor's muscle memory.
I have an addon installed in firefox that lets me use my Vim muscle memory in firefox.
Consider e.g. e-mail in Emacs[0] as on this screenshot: [1]. Both the list and the message you see on this screenshot are read-only UI, like in any terminal-oriented app. Except that I can navigate through and manipulate them with all my usual Emacs shortcuts, including:
- using incremental search to find a message of interest
- doing regular Emacs region selection over multiple messages, to apply the same action to many of them
- semantic expansion of selection
- using selection to spawn multiple cursors at appropriate places, and then apply the same actions under each cursor
- using M-x occur to do a "grep" on contents
- using regexp highlighting to highlight lines or words matching regexp
- using narrowing and widening to display only a subsection of the e-mail list
... and many more, and all those examples didn't even touch e-mail-mode-specific things! That's just text-editing shortcuts over text UI! Those are all the things you'll have in your muscle memory as a proficient Emacs user, and you can use them everywhere - be it IRC, terminal, a REPL, list of e-mails, etc.
In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow - and I have access to very advanced/complex actions (plus the ability to write my own, or download them from the Internet).
Oh, and even if read-only, the UI is still text, so I can just mark it all, copy over to another buffer, and process it as if I was working with a plaintext file. No need for scrapping anything.
EDIT: changed "expansion" to "widening" in the point about narrowing.
--
[0] - which I just managed to get working, thanks to friendly HNers that responded to me here: https://news.ycombinator.com/item?id=14569833.
Narrowing and widening to be precise. As many Emacs features, narrowing seems useless at first, but it has surprisingly many uses. Especially with `expand-region` installed: no matter where is my point, I can quickly select current block, narrow the buffer to it and start using bulk-edit tools, like `iedit` or `multiple-cursors` while being sure that they won't affect other parts of a file.
> In this way, "Emacs OS" UX is superior to my "host" OS UX (be it Windows or Linux), because I can perform all those actions in an unified way, without breaking my flow
I still use the combo of urxvt+tmux+zsh though. I could probably get most of the same features with Emacs+Elscreen+Eshell+Auto-Complete/Company, but setting it all up seemed like a lot of unnecessary work, while I had my `.tmux.conf` and `.zshrc` already configured before switching to Emacs. I'd still love to switch to Emacs for terminal emulation, but all the available options right now (from eshell to ansi-term) lack some important features I'd rather still have.
I have the same thoughts about available terminal options; I'd love to use Emacs for my terminal, but unfortunately there are always corner cases that annoy me enough to keep me stuck to urxvt + fish.
What's great is that the .stumpwm is just Lisp code (just like .emacs) and every window management function is available (just like in...Emacs). If there's an error somewhere, you get the full power of the condition/restart system, so your WM doesn't just crash, you can recover interactively.
And with quicklisp, there are so many Common Lisp libraries available, it becomes very easy to script StumpWM however you like...all without leaving Emacs or restarting the WM or anything inconvenient like that.
I feel like this philosophy (editing a program while it's running) isn't really found in non-Lisp languages. Which is such a shame, since I think it's really useful and cool.
I am not sure if sarcasm or what. It's way worse then IRC because it's so damn slow.
The trouble is, it's too far to the right. Some people don't respond for days. So we have tools with instant response expectations, and ones with variable expectations. Nothing with clear "within a day" expectations. Email used to be that way, until too many peed in that pool.
Slack, then Mattermost, solved that for us. Our email inboxes became crowded with banter, notifications, as well as info that should be tracked in a centralised place. It was a mess because email became a kitchen sink.
So now we use GitLab for most of the serious "this better be tracked" stuff, Mattermost both for the off- and on-topic live chat, and email takes back its natural place when interacting with third parties (those we didn't onboard on GitLab), reply-soon-enough, and notifications (including GitLab ones, which thus covers "reply-soon-enough+should-be-tracked" in a seamless way).
The key point is having the three tools together, personally configured as each user sees fit WRT notifications, allows for each tool to blend with each other over the gradient of possible use cases.
This is pretty much purely a social issue, and should be set by the management / work culture directly. Nobody can force you to reply to an e-mail any more than they can force you to reply to a Slack message.
Because in private, I try to push as much communication as possible through e-mail exactly so that I don't have to reply to anyone within 24 hours if I don't feel like it.
Edit: Yes, it's a people issue . Wasn't trying to frame it as a tech one. We've ended up with two paths, reply now (slack, other IM, sms) or reply/maybe/never (email/voice). For people reasons, as you say.
There have been some attempts to use tech to solve it. Google's inbox, for example, might have helped unclutter so you could see what was important.
I'd rather see something built from the ground up to get it right. Hiri for example ( https://www.hiri.com ) tries this for email - https://www.google.ch/amp/s/techcrunch.com/2016/06/07/hiri/a... - the product even includes features to rate colleagues emails and help them improve.
By contrast I'm pretty sure if we could review Slacks internal documentation we'd find it's been built to be addictive by design: its intended purpose is to consume every second and minute you give it because that drives its growth and success.
The idea of communication feedback as noted in Hiri is interesting, but I'm not sure it works well with a more spontaneous and instant communication medium like Slack; chat lets you do off-the-cuff responses. Sometimes it's a curt-but-true "check the documentation", other times it's a longer but quickly made wall of text. Likewise, typically we write differently when there's a larger audience than we do with it's just an email back and forth with a colleague; at my last job, I definitely took a different approach talking to my student employees who were there to learn than I did with my colleagues who should already have some foundational knowledge of the topic at hand.
I forget where it was said first, but anything you measure will impel a person to optimize his score on that metric. (taken from Harvard Business Review) Competing and/or contradictory metrics can cause a lot of difficulty in a chat environment like Slack which I think is meant to foster more spontanaeity than it is a specific style of communication. It is important to curb bad spontanaeity (e.g., aforementioned gif shitposting), but outside of general "avoid this" rules, too many and you start to make people feel nervous or unwilling to participate, especially since the weight of feedback is pretty great to many people; just look at how self-censoring "Likes" make people.
That's just the tip of the iceberg though, since it seems like an almost natural instinct, at this point, to make a whatsapp group chat for everything. School group projects are also added to whatsapp groups and with these everything the author has listed is true. Probably even to a greater extent.
In one project I did a couple years ago our group never met physically for 99% of the tasks, all the meetings we needed to have happened over group chat - bearing all the problems listed in the article. I know for a fact that the resulting work was diminished because of this. Yet, people seem almost enthusiastic about transferring work to whatsapp.
Even in my office I've never met anyone with a problem flipping between the correct communication technology for whatever task.
We switch pretty seamlessly between,
* Email (with Outlook's calendar feature for organising meetings).
* Face to face meetings, (formal/informal, presentations, etc)
* Instant Messaging for time wasting but also for quick answers too. Almost always 1-on-1.
* Telephone for awkward but super useful communication with field crew.
* Atlassian's Jira. This is a recent addition and directly addresses many of the flaws of using email for coordinating projects. There are probably heaps of similar solutions out there, but I am enjoying this one.
The more channels the better!
It seems like something more like personally messaging would solve the immediacy problem. Open a PM (Slack, FB Messenger, Hangouts), add the people you want to include in the discussion, start the conversation. Only those people are notified, if more needed to be added they can be added. That would seem like it would prevent more of the constant distraction part.
Talking on a channel is more like talking aloud in a team room with one or two people, the other people are allowed to overhear and join if they have some input. Or they can put on their headphones or tell the noisy people to get a room or shut up.
With a team chat system you can just disable the notifications when you don't want to be disturbed and read the backlog afterwards (if you're so inclined). No need to tell anyone specifically to stfu. You can also be invited to the discussion with an @mention and you can immediately read the previous comments and join in without anyone having to spend 5-10 minutes re-explaining everything to you.
That's annoying enough on the real world. When an application not only makes it the default, but makes sure you are placed in a bunched of noisy rooms at the same time, it's bad.
There's no reason for "room" notifications to be enabled by default on any application.
We use Hipchat, so I can't speak for slack, but notifications are only sent out if someone "requests" a notification like @all or @here (those not AFK) or @personName for an individual notification
Each team has their own room as well as a global company room and a social "hangout" room. If you want to catch up on things you are welcome to chime in later or add info to the room/ticket but you are not required if you aren't a stakeholder.
I am never distracted unless someone needs to distract me for an immediate need.
"But the reality is that tools encourage specific behaviors. A product is a series of design decisions with a specific outcome in mind. Yes, you can use tools as they weren’t intended, but most people follow the patterns suggested by the design."
Reminded me of "our writing tools are also working on our thoughts". Our brains are pretty plastic and will adapt to 'the rules of the game' and I imagine that these days, those rules are defined by the affordances provided by the software.
Chalk it up to defective website design.