I never truly understand issues people have with these things. I tune my notifications as to avoid true interruptions and filter most false positives by quick looking.
I see people at my office (and different companies!) saying they quit Slack/Whatever because they were getting bombarded by notifications... They had the option to notify on all messages. ¬¬
Even then, come on, I cannot believe experience hasn’t taught most of you how to handle quick interruptions. I usually just quick look at the notification to see if it’s really urgent. Otherwise it may be 7-10 minutes until I actually check the application, in case I’m doing some heavy thinking/coding session.
There are true interruptions like constant notifications, people physically talking to you about other things, and stuff, that while you cannot really tune them all out, you should be able to handle better with 2-3 years of experience. I read a lot of people on these forums with many more years not being able to cope with that.
I will die still unable to believe it was the norm, and not the exception :(
> I never truly understand issues people have with these things. I tune my notifications as to avoid true interruptions and filter most false positives by quick looking.
You've answered your own question. The product is distracting by default.
The savvy user can cut down on the distractions by configuring notifications, teaching themselves how to scan messages, etc., but if there's one thing we know from 70 years of writing software it's that most users accept whatever defaults you give them. Sometimes that's because they don't know they can reconfigure the software; sometimes it's because they do know they can reconfigure it, but can't figure out how; sometimes it's because they know how to reconfigure it, but are too busy with other things to do so. But the underlying reason doesn't really matter, what matters is the general effect: the default experience the software provides is the experience that most users are going to have with it. And with Slack, the default experience is distracting.
> Even then, come on, I cannot believe experience hasn’t taught most of you how to handle quick interruptions.
How many threads have been posted on HN complaining about things that take programmers out of their state of "flow"? How many programmers have you met who are happy to hear their phone ring when they're working?
> There are true interruptions like constant notifications, people physically talking to you about other things, and stuff, that while you cannot really tune them all out, you should be able to handle better with 2-3 years of experience.
2-3 years studded with bouts of lost productivity is a lot of lost productivity. A product that tells me my life is "only" going to suck for 2-3 years while I learn how to use it is not a product I am going to be thrilled to use.
> How many threads have been posted on HN complaining about things that take programmers out of their state of "flow"? How many programmers have you met who are happy to hear their phone ring when they're working?
Those are what the true interruptions are about. A notification? I'm sorry, but after less than a month one learns how not to let a simple sound or notification distract you. Constant phone ringing is a true interruption; one ringing loop? Not so much.
> 2-3 years studded with bouts of lost productivity is a lot of lost productivity. A product that tells me my life is "only" going to suck for 2-3 years while I learn how to use it is not a product I am going to be thrilled to use.
Handling interruptions is about not letting them make you lose much productivity, but after all, this is for true interruptions. They will affect you, but there are ways to lessen the effect. If people allow other people to constantly interrupt them without setting clear boundaries/priorities, it's your (or your Manager) problem. I usually set things in the clear from the beginning, and after two or three times, it'll never happen again. But again, these are true interruptions: Some are necessary, and those which are not can be handled better.
Your premise is based on the intersection of "most users" and "programmers". I don't really buy that. Do you know any programmers who are hopeless with tool configuration?
My problem (with Skype, so ok that's two problems) is people just put "hi" or "hello" and then the choice is to either ignore them and hope they'll get around to actually asking the question, or give in and say "hi" (passive aggressive or "hi, what's up" (I don't care what's up - you started it). I can't think of a polite way to say "please don't just type "hi"" without making it sound like I think I'm special, but at the same time ignoring them outright seems rude. They know I'm here because of the presence indicator.
> I can't think of a polite way to say "please don't just type "hi""
I feel like I've seen something similar as a general rule. If your company has any sort of internal etiquette guide for its internal communication tools, this should go there verbatim. If not, then it can still work to post it in certain places; for example, a slack channel where people ask your team questions.
If you're getting asked questions but your teammates aren't, then you are special! So just tell them directly. Even better, respond to the DM saying that for the benefit of everyone, such questions should be asked and answered in a public channel, so that others have a fighting chance of finding it with a search tool. This eliminates the "hi" problem entirely.
This is my biggest IM pet peeve. When someone separates their "hello" from their actual question, my attention is broken for 30 seconds to 5 minutes for absolutely no reason whatsoever until they send it.
Just ignore when they say hi. They'll eventually learn that they don't get a response. If they actually talk to you about your "rudeness" explain that you only respond if it seems urgent, and "hi" isn't urgent.
There's a guy I work with that does this _in real life_. Let's call him Bob. Bob sits maybe 15 feet from me in the same room. We work on the same kinds of things. In this company, it's encouraged to engage with others immediately if you have a question. If they are too busy right at that moment, they will tell you and check back with you later and everyone knows not to take offense in these situations.
However, Bob pretends to be afraid of me. People walk up to me all the time when I'm working and ask questions and it's perfectly fine. But when Bob has a question, he _whispers_ to get my attention. Or he'll stand just in the periphery of my vision and literally wave until I respond. I've told him, nicely, more than once, that he can just talk to me whenever he wants. His response is always along the lines of, "well I didn't want to break your concentration" or, "I didn't want to bother you if were busy." Bob knows I don't ignore people whether I'm busy or not. I don't want to believe he does it just to annoy me but I'm failing to come up with a more logical explanation.
I know! And it's so frustrating, because it's so easy to just include the question as a part of the first message (e.g. "Hi! Could you help me with feature X?").
I've been trying to think of a good way of asking it. Maybe something like "Just so you know, I won't be offended if you ask the question with your initial greeting. It would actually be helpful because then I can start thinking about the answer right away. :)" Does that work?
No, "they" don't. Some people do, sure. But some people are doing as the parent mentioned; ringing the phone. Letting you know they need to have a discussion with you, so you can reply when you're ready.
Pretty true. The worst is when they butter you up a bit with, "how was your weekend?", or "The weather is pretty nice today". Like they actually care about you, ha!
Ironically, I once got feedback from my team lead that when I would start with my question without first pinging with a generic "hello", it seemed demanding.
I would usually say “Question: <question>”. The latter might have been okay; after the feedback I just switched to “hey I’m stuck” or “Hey I’ve got a question” and asked the question after he replied, which he was happy with.
That's fair. I sometimes do that too, especially if the question is somewhat long and complicated (though I that point I usually ask if I can just call the person). But at least that's more than a solitary greeting.
It's this worry that causes me to prefix non-urgent things with something like "Hey, question when you get a chance, XXX".
What feels demanding to me is coworkers who will simply send a message containing my name, sometimes followed by a period. Opening slack to see just "John." (not my actual name) is somehow both more and less personal than "Hi". I believe it's mostly a language barrier thing, as it's only ever ESL speakers who do it, but it still feels like nails on a chalkboard for me.
> I can't think of a polite way to say "please don't just type "hi""
Here it is: "please don't just type "hi"". It's that simple. I've never had anyone perceive that as rude or negative in any way, and they usually adapt pretty quickly. If they don't learn, you just have to step up your ignoring game ;)
Yes, in my case it's "hey" followed by silence unless I acknowledge. I mean, gee whiz, this isn't a phone line dude - just spit it out already. The person in question has zero abilities to learn lessons or develop empathy so I am resigned to the idea of dealing with it or finding a different place to work.
This drives me crazy too. Would you send an email that just said "hi"? Didn't think so. Is it that hard to just say "hi, [question]"? Instead I have to reply and then wait for them to type their question since I've already been interrupted.
It's not the abyss, it's just asynchronous. If you make me say hi back then you have trapped me rather than giving me the option to look at your question, determine the importance, and respond at a time that is appropriate for me.
Because the alternative is to waste the time of the person you're talking to while they sit there waiting for your follow up. You're already interrupting them; no need to make it worse.
Yeah I'm not sure why the slack good / slack bad discussion warrants as much discussion as it does.
It's just a communication tool.
Either it works for you personally, or it does not. I don't think it deserves a weekly HN first page discussion though.
I didn't read this as a slack good / slack bad article at all.
At my current job I was asked to join a client's slack group (added without my consent) and it was a nightmare. The problems have nothing to do with notifications or interruptions, but it gives them the implicit understanding that I am a custom developer for their needs. Since they can reach me at any time, they assume that I am going to fix their bugs, add their features, etc. It circumvents what I think is the proper procedure for work. I suspect that's more the heart of why the author is saying they aren't going to join their client's slack group.
This seems a lot like you making assumptions about their expectations and/or acting on their expectations/your assumptions; rather than acting the way you think is correct.
If you aren't their personal dev, then don't be one. The only thing my presence in a client's slack means is that I (and/or the other people from my company in their slack) am reasonable first point of contact. I'm perfectly happy telling them that their problem is not one I can solve (or choose to prioritize), and that they should touch base with <appropriate person>.
I guess my story was unnecessary, but I commented that I didn't read the article the way the person I responded to (and the person above him as well). I don't understand why the top rated comment is worded in a way that sounds like the article was bashing slack because the Author of the article doesn't understand how to focus...when I read the article and saw nothing that led me to believe the top level comment was on topic. So I commented.
If I am ok to carry on this tangent we are already on, I cannot wrap my head around a scenario where it would be appropriate for a member of a SaaS company, dev/PM/CTO/QA or what have you to be in a slack channel for one of their clients. It's completely unprofessional and should be avoided.
This is mostly about setting expectations with the client. If they slack you most of the time they expect to hear back soon, or else they probably would have used email. So they opted to make it clear and just not use slack. Makes sense to me.
> I never truly understand issues people have with these things. I tune my notifications as to avoid true interruptions and filter most false positives by quick looking.
The problem isn't the notifications here. Sure, I can tune my notifications to my preference, but when you're a resident in a client's Slack the expectation is that they can directly message you, anytime, for any reason, and for any size request. Like the article says, Slack does not encourage deep and meaningful messaging – it's more like a text. I have found that opening a channel like this almost always brings with it a firehouse of small changes requested in bursts, whereas a single e-mail encourages bundling of issues and requests into minimal amounts of messages. The worst thing about Slack is the constant "10:00am: hey HBOSCH, can you do X?", "10:15am: oh, and can you also do Y?", "10:47am: and while you're at it, maybe you could handle Z? haha sorry for being crazy!", "10:49am: <silly gif>". It's so annoying.
I also tune my notifications effectively by using Do Not Disturb mode on my iPhone from 12:00AM to 11:59PM, along with the "Bedtime" feature in my alarms. This keeps my phone quiet all day, only allowing phone calls from people on my Favorites list to come through, and the Bedtime function in Alarms keeps my whole device totally silent from 10pm to 6am. But that's not helpful if a client is trying to reach me at 8am EST when they need an emergency update before a morning meeting.
> The problem isn't the notifications here. Sure, I can tune my notifications to my preference, but when you're a resident in a client's Slack the expectation is that they can directly message you, anytime, for any reason, and for any size request.
This is kind of true. I work with several partners of our ecom platform using Slack. Most of them are not that responsive, and that's fine - Slack is a chat app but it's still asynchronous! As long as people answer reasonable queries in a reasonable time (so e.g. within the working day) then it's fine. I never expect instant answers.
People are lazy. They can't get themselves to change the defaults. It's a barrier they see too high. Pretty much why iOS is great because it "just works". Designing an HCI (Human-Computer Interaction) system is really hard.
I think they are best understood as the modern equivalent of circa 2000 era virtue signalling "I don't watch TV, we don't even have one in our house". Except now people do it online on HN because their IRL friends are sick of hearing them talk about it.
There are modes of work where Slack or another instant messaging option make me far more productive than anything else, and there are modes where it makes me far less productive.
When collaborating on a time sensitive issue with remote colleagues it's fantastic. When trying to get my head down and complete a tricky bit of work it's awful.
I think the most important thing is not using Slack or avoiding Slack, it's building a culture that allows people to opt-out of it, without any sort of penalty, perceived or otherwise. If people want to hang out in Slack they can, if they want to shut it off for the day and just drop in to give a standup update or something like that, that's fine too. Important things are done asynchronously in a forum that everyone can experience.
> Important things are done asynchronously in a forum that everyone can experience.
This is how email or ticketing systems to an extent work. Though we have a rule that certain ticket discussions should go into a ticket itself so decision changes are not lost and people have accountability (which is better cause I get asked sometimes why I wrote code a certain way by the very person who suggested the change).
> we have a rule that certain ticket discussions should go into a ticket itself
The last three companies I've worked at had the same rule, except with no exceptions. All discussions get recorded into the system, precisely for the reason that you state -- so there's a historical record of what was discussed, what was decided, and why.
Any "external" communications, such as with email or IM, are expected to be copy/pasted into the system so its permanently recorded in a useful way.
Most places that I've been at that have worked this way have had periodic "checkpoints" in the tracker (usually when the code involved is sent to QA), where the current state is summarized at a 10,000 ft level.
In practice, these records are only read from beginning to end when someone new to the issue at hand needs to come up to speed. Otherwise, the value is in being able to search through the record to find specific things.
Jira has the ticket description section which gets updated to the latest goals / spec as things change. The history is for context of "who said do this" / "why did we do x"
> I get asked sometimes why I wrote code a certain way by the very person who suggested the change
This drives me crazy. Even worse is when I get told out of the blue that something I did is wrong, by the supervisor who told me to do it that exact way some months ago.
This has happened almost everywhere I have worked, and none of those places kept change discussions to a specific ticket. I'm going to push for this approach more in the future, it sounds like the right solution.
Yep. When we started our support was done through individual emails or a general support email (not tied to a ticketing system). That was fine when we were a 5 person company with 3 big customers.
As we scaled, we had to transition to a ticketing system, for the reasons you mentioned.
Slack definitely feels backwards in some ways especially if you use it as a channel for dealing with customer requests, especially if multiple people at customer site are part of the slack group.
Send the requester an email about the decision asking if you understand their request correctly. Then save your emails (keep copies of them off of company computers so you have access to them in the case of unlawful termination).
There are very few things considered an “unlawful termination” in at Will employment. A difference of opinion about an implementation is definitely not one of them.
A company is very unlikely to ever side with a subordinate over their manager.
I'm not sure if this is unlawful termination, but I have a friend who was recently terminated with cause. The cause was supposedly lying about something. He had proof in his emails that proved he was innocent, but he has no access to his emails and was told all his accounts were deleted immediately on termination. What actually happened is some higher ups who had no hand in his brainchild saw how successful it was and wanted him to put their names on it. He refused (in retrospect, stupidly) and thus was fired so that they could take it over and claim it as their own. Because he was fired for cause, he has no severance, unemployment, cobra health insurance, etc. If he had copies of his emails it would be an entirely different story.
Out of three, severance is not a government guaranteed thing. If he signed a contract before he was hired guaranteeing severance (which usually doesn’t happen) he could file a suit.
If he had his status changed from fired with cause to without cause, it would have made a difference in his unemployment. I do not believe that they could deny Cobra. Why would they? He would have to pay the full cost with no subsidy from the employer.
That's why Basecamp is better suited for work in my opinion. Don't use chat to solve problems. Use longform text like messages. And avoid notifications.
Allow your team to response in a matter of hours/days, not minutes. Let them think about and rethink a problem or question.
This requires to be able to work on a couple of problems at the same time. Divide the work accordingly. Or use the time waiting for a response to learn something.
There's a quote going like this: The urgent is not important and the important is not always urgent.
> Allow your team to response in a matter of hours/days, not minutes.
This does assume only one of the kinds of work that I mentioned though.
If our database server goes down and the site is offline and we're losing money, that is when Slack shows its value. We have a full log of what's going on, we can rapidly communicate statuses to stakeholders, we can debug things in realtime even if a distributed team.
I'd love to not have those sorts of times, but there's always going to be times like that for almost any business, any type of work. They can be minimised, but sometimes you just need fast communication.
In that way, I see Slack as a better long-run conference call. I can dip in and out as needed, it's got rich information, it's easy to look back through history. For things email is good for – let's stick with email.
“This requires to be able to work on a couple of problems at the same time.”
...which is a really bad idea, because context-switching carries a heavy productivity penalty. Many studies show this clearly: even though people may feel more productive when multi-tasking, they actually are much less productive, and the solutions they come up with to complex problems are more likely to be wrong because they haven’t spent as much time in the same context (i.e. asked for help, couldn’t get any on time, was forced to switch to another task/problem).
Working on two or three projects concurrently over the course of two or three weeks is not the same as multi-tasking. If you’re expected to immediately respond to things and have multiple projects going, yes that’ll be trouble. But if you’re able to pace your own work, and respond in hours/days, you can be more than capable of holding more than one thing in your head.
"Last week I needed to reboot dsr55rhel. I was blocked for 8 hours because of the way we communicate things. To avoid this next time, I suggest we: ..."
"Last week I lost 3 days of my work because someone rebooted dsr55rhel and I didn't see the reply in time. To avoid this next time, I suggest we: ..."
There are probably cases where it's necessary for multiple people to be communicating/collaborating on some issue simultaneously and synchronously. Most won't be.
I think cases like "what if something comes up and you need multiple people" is a smell that something can be improved, rather than a common unavoidable problem.
Is anyone using dsr55rhel? I need to reboot it. 0:00
Is anyone using dsr72rhel? I need to reboot it. 0:05
Is anyone using dsr21rhel? I need to reboot it. 0:09
Is anyone using dsr97rhel? I need to reboot it. 0:11
..ad infinitum
1 Month Later, some over the top, ITIL compliant business-flow is setup to quash that nonsense. And now everyone is suffering the consequences with hyper bloated business process procedures.
...basically the disease, the cure, and the cure for the cure are all equal when killing productivity.
It really comes down to people and discipline. You're either working with smart, competent, well adjusted adults, or you're not.
If your organization is small, brilliant, tight ...then any/all decent tools can be utilized to maximum effectiveness, because again it's people.
But the larger the organization, it mitigates any and all tools, even the best of tools, and it also mitigates the possibility of having a small collection of really smart, talented people. Smart people in this environment typically will feel suffocated in a few years, unless they are protected from the endless nonsense that large organizations naturally create. This is how brilliant managers operate, and the competitiveness is interesting to see. Savy manager, makes his way up the food chain by being a problem solver. How does he solve it? Pooling talent, shielding them, in exchange he has high expectations from them, they come through, all are heroes, but the manager gets majority of credit. He/she then gets moved to a higher level, or a group that tackles harder problems. He streamlines the group, gets rid of the dead weight, steals better talent from other teams, protects his team pushing the boundaries as granted to him/her due to previous successes, then uses the potential to solve problems that no one else can/wants-to solve. Wash Rinse Repeat.
If someone regulary utilizes a broadcast to ask everyone "who is using this server, anyone on it, can I reboot it?"
Something is terribly screwed up at that organization. And having Slack as the broadcast tool is just an enabler.
If you work in an environment where the 'rules' are followed then yes, that works fine. Turn off the notifications and go about your task.
However, not everyone has that luxury. In my office, we are required to keep slack running.
There are bullshit channels like #random, #memes, etc. that I have set to ignore. But then there are "Serious" channels where if the Boss speaks the expectation is complete participation.
#General <Boss> I want to make all the icons a corn-flower blue across all of our sites.
--Now here is an example of the boss being an idiot and interrupting 30% of the staff. The accountants don't care, neither do the secretaries, the Help-desk, the Customer-support, or the SysAdmins. But because the idiot starts the conversation in the wrong fucking channel every damn reply and conversation that is sparked because of this interrupts me.
Incorrectly using the "tool" disrupts everybody who does use it correctly. If this was an email, it'd be safely ignored for 4+hrs. I'm not mad at Slack, I'm mad at corporate overlords who shouldn't even be allowed to touch a computer.
But because Slack exists, I am forced to despise it.
I've got half a dozen other ways to send IM's to my co-workers. I never got interrupted in the past with bullshit like I do with Slack.
But turning off notifications is not using the tool right. The fact that you have to turn off notifications indicates that most people use it incorrectly (e.g., @channel/@here-ing for super unimportant messages).
Slack does a really poor job of guiding its users to use the tool properly. There is no warning when someone decides to @here the #announcements channel with 200+ people to wish someone a happy birthday. That's poor design.
If you can't opt out of it completely, that means that there is some socially-determined expectation as to how responsive you're going to be. Not everyone can unilaterally set their own level of responsiveness without a negative impact on their standing in the company.
That's exactly my point, but you need to be in a company where that's an acceptable thing to do. I'm lucky to work in a company where "I'm sorry, I was offline getting stuck into some work" is a very reasonable response, but it seems like much of the criticism of Slack comes from companies where that's not possible, or people who don't have the discipline to actually log off (which I am definitely guilty of at times!).
>I think the most important thing is not using Slack or avoiding Slack, it's building a culture that allows people to opt-out of it, without any sort of penalty, perceived or otherwise.
The new book "Indistractable" makes exactly this point. Incidentally it also talks about how the Slack company uses Slack, and this is exactly their point, too.
The book goes on to talk about "Psychological Safety." In this case, defined as the lack of '>any sort of penalty'
> When collaborating on a time sensitive issue with remote colleagues it's fantastic. When trying to get my head down and complete a tricky bit of work it's awful.
I have found slack to be wonderful when troubleshooting production downtime. Not just during it, but after, for the post mortem.
Other times I try to treat it like email. That means turning off the notifications and closing the client for long periods of time.
When there is a live issue I like to get everyone on a call and just keep it running even if there’s nothing to say. Just the little sounds of puzzlement or frustration are sometimes a clue to open up further conversation
problem with any messaging system is people abuse it / don't respect other peoples time, and software can't control for that. people have to own up.
an example not necessarily tied to work directly: there was a slack channel at work that was dedicated to free food. if you brought in food, or someone or a vendor was giving out food, you told the channel what food / when / where + an optional picture. Problem was, some people would just chat - about their vacations, dogs, etc and I would have to ask them to take it to another channel or talk direct message, because they would bury actual food announcements and cause all sorts of notifications. instead of realizing their folly, they would fight back and say you can always mute the channel, which totally negates the reason for being in the channel.
You also see alert crepe. someone has an idea of sending service information to a channel, and before you know it you have 25 channels dominated by computer talk.
I disabled all notification from slack every platform I have it. Same with email, facebook and all the other platforms that designed to disrupt your normal workflow or life.
Yes, that's what they say. It's like closing an HTML tag.
I disagree that nothing more needs to be said about Slack, though. It's a highly influential application, for better or for worse, and the social issues around it aren't opened and closed quite so easily as a div tag.
Even a customer "should" know that Slack is no small matter.
I worked in a support role for a big company. We had one notorious customer who was prone to just racking equipment, not setting it up, and calling in priority 1 support cases to basically have us configure it for them with little to no data / would not do what we said. (this was their SOP, and they're also a huge company...)
We used Microsoft's messaging service at the time and I had no idea that IT had configured it to allow people outside our company to message us.
So as you might expect one day I'm working another customer's "real" network down priority 1 case and I get a frantic message from someone I didn't recognize asking a vague question as if we were in the middle of a conversation. I assume this is some sales guy I never met frantically messaging me (some sales guys knew me and handed my name out as I was friendly and I'd help them out if I had time). But then I can't find this guy in outlook and suddenly I realize.
So I mute my mic and announce to my cube mates "Guys... X company is instant messaging me ..." The response was hilarious, managers came running, some folks announced they were shutting off their laptops ... it was immediately clear that this was an untenable situation.
Fortunately the solution was right in front of me. In another conversation I had a sales VP in on a chat for the customer who had a "real" priority 1 case. I told him that I was receiving instant messages telling me I needed to stop helping his customer and go help X company. Granted I wasn't actually going to drop him and I phrased the FYI in a way that made that clear, but also let him know he had some competition for my attention / our focus on his customer's issue.
Suddenly we had a Sales VP as an ally breathing down ITs neck to shut off outside access to the support team's instant messaging.
At one point management had the idea that we should do "chat support" on the website.
The website (a god awful mess) was run by the marketing department (that's why all our handy documents were hidden from the world) and they took the lead and suddenly announced support was just gonna be available to "chat" 24x7... and support via twitter would come soon too... nobody in support knew anything about it.
Thankfully even the CEO recognized the amount of manpower it would take and how bad an idea that was for what often were complex issues.... and really most social media and chat contacts were from folks who bought second hand equipment and had no support contract.
I've known a few people in my life who could talk anybody, including themselves, into any stupid idea you could imagine. And then talk themselves out of it again in six weeks. The whiplash is tremendous. I've started applying advice for talking to addicts to my conversations with them (supportive, but don't invest in it). It's so disruptive. And personally, I find it exhausting.
Most of them have been in sales, at least once.
Promising things that the company can't possibly deliver for a price that will bankrupt you. Classic marketing dept.
Your description of whiplash resonates with me. One of the most common bad management traits I've run into is constantly changing priorities. Typically in these environments every single thing is an urgent crisis, but the super duper critical stuff from earlier in the week almost always gets completely forgotten about because 1) It was never actually that important, and 2) Everyone immediately has to jump on the next "crisis".
Working in a place like that is exhausting, but very little ever seems to get done.
I definitely feel this one. Slack reminds me of the open office plan, in that it seems like a solution to a bunch of problems, but in practice creates a whole new set. It's also a bit like having a candy dish within arm's reach. In theory, I should just be able to say no, but in practice I know I'm going to eat more candy than I want.
I'm definitely more productive the days when I keep Slack closed.
I can recommend Zulip. In one of the instances I'm on, we have a rule that "topics outside of #random are treated like email". People are supposed to post multi-paragraph posts that go into detail, and replies are similarly long and quote all relevant parts.
I love that mode of communication, it feels less like drive-by opinion-slinging and more like conversation.
> Slack reminds me of the open office plan, in that it seems like a solution to a bunch of problems, but in practice creates a whole new set.
Slack solves actual problems, open office plans exactly one: managers can reduce operational costs and with them raise -their quarter/yearly boni by cramming more people in less space, just like a herd of chicken moved from free range to a huge mega stable with 1 DIN A4 space per chicken. By the time the epidemics race through the chickens (=workers flee) the manager responsible is long gone and cannot be held accountable any more...
When I ran my own consultancy, I went on holidays for a month once, leaving the company under the management of a long time employee.
I came back to find an employee of one of my customers sitting at a desk in our office. Turfed him out. Had to "fire the customer". Lost about 30,000 euros of work time and unpaid invoices.
In my view joining someone's Slack Channel would be no different than that little piece of "management kidnap". Everyone in the office had completely turned their attention on that single customer's problems.
I read it as the customer wasn't happy with something, and having learned that 'the boss' was on holiday, decided to parachute in their own management to oversee things.
that could very well be it - but I'm not sure I'd leap there - as someone who has been embedded inside my customer sites for months at a time, its not unusual for me to get attempted micromanagement from the customer - I've learned how to push back both politely, and impolitely, as the situation calls for.
They learn that you will say no, every time. So they ask someone else, and someone else, until they get the answer that most resembles what they were after, then they lock into that as a commitment instead of a hypothetical conversation.
As a child you figured out which parent was more likely to say yes to treats, and under what circumstances (mood, which sibling asks, how they ask).
The thing is the customer gets rewarded for results, no matter how they get them. So if they stoop to juvenile tricks and get a promotion for it, they're just gonna keep doing that forever.
I'm not the person you were replying to, but my reading of the situation is that the customer realized the boss was out of town and so they sent their own manager to ensure that their issues got priority over everyone else's.
Interesting. It's not uncommon for consulting agencies to bring client employees in house for a few days, or vice versa, in order to work directly with one or two people, and this doesn't mean the whole office is focused on working for the visitor, but of course in your case it may not have worked like that.
We have a couple of shared channels with companies for whom we are customers and it also does not feel like that. The other company assigns one or two resources in each case to helping some of our staff with issues when they come up, and we pay them for that support. Only a small number of our team would be a member of those channels.
I had the opposite experience. A client of ours was souring on us and we invited them to our Slack to try and help them with some issues. Slack was the easiest way to help work through their issues. The ability to quickly and fluidly clarify ideas in a conversational manner as a discussion is ongoing make it far superior to email for technical conversations. Often in emails people seem to talk past each other, as there is too much time between emails and people lose track of the conversation too easily.
Video calling might be even more efficient during the call itself but personally I would spend so much time thinking about the call, preparing or worrying before the call itself that it would be a bigger drain on my productivity overall.
Not to mention that my personal productivity is not even the most important thing. In this case these Slack conversations fixed a client relationship and moved our work with them forward in a way that was far more valuable than any SLOC I could have produced in that time.
Yes, all their reasons for not joining a customer slack seem reasonable, but none of them seem related to the 25-year theme. They are all about problems in the here and now, you don't need a quarter-century-long stare to see them.
I felt that it was laid out fairly well in this essay. They described their 25 year rule, and described a lesson they learned in the first 18 months of their company from a few attempts really wasn't working for them. Because they learned this lesson early on they refused a client's request because they were confident in the lesson learned not providing the right kind of value for their organization or their clients. Their rule biases learning from early things that don't work so that they can focus the most energy on things that are working.
Same here. I thought the article was going to talk about vendor lock-in and the inability to access old chat messages if their client removes their access, or if their client stops paying Slack, or if Slack stops existing. The hard turn into that mainstay of startup blog posts - "Slack makes us unproductive" - felt abrupt and unmotivated.
They could see that though they could handle joining a Slack or two now, doing it repeatedly over 25 years would shape the company in a way they didn’t want.
Absolutely. Nothing has destroyed my productivity over the years as effectively as the expected instant response from ICQ, instant messenger, and Slack chat messages.
I like this essay. I'm not anti-Slack, but I'm not much of an "IM" person. Partly comes from the way I work (I get "zoned," and don't surface for hours), and also because I used to work for a Japanese corporation, where IM was worthless.
I like the fundamental ideas he puts out:
• We felt busier, but were getting less real work done
• We knew the clients better personally, but we knew the product less
• We had more superficial conversations, but fewer substantive ones
• We were able to react more quickly, but our responses were less measured and effective
That said, Slack is a pretty cool tool, but there's lots of cool tools that I don't use that much.
I hate Slack. It started as a copycat of Yammer and didn't grow outside of that. It doesn't have native apps on the Desktop and although they've improved things a lot, it still not as good as it should be. Compare it to Spectrum, let's say, which builds up profiles and is affordable. Why I can't have a single profile, which I use across different companies? Why do I need to create tens of accounts? Don't they get what "identity" is? On top, they shot themselves in the feet not building identities as that opens the door go grow well beyond Yammer. What I don't get it why developers still choose it - it's code-pasting unfriendly, it converts your quotes and dashes - even in URLs. There's no syntax coloring, etc. Microsoft Teams is much better although it suffers from many the limitations of Slack - including the limitations in the vision. Slack is not a replacement of email either - it lacks basic features to be a replacement. In general, I don't think Slack will survive this as Teams appears to be winning.
Some teams fundamentally don't work to work in something like Slack, anywhere. That makes sense.
If you're using it internally, though, it probably makes sense to use with high-value customers, too. Slack's shared channels go a long way toward enabling teams to stay in their own space, on their own terms, while working together.
On its own, Slack isn't as well suited to working with customers -- notifications and confused ownership get complicated, and stuff starts to slip through the cracks.
We've helped teams scale up Slack-based support and customer management with an add-on called Frame for Slack (disclaimer: I work at frame.ai).
With @frame sitting in the channel, it's way easier to manage these channels just like a support system. Tailored escalation schedules to fetch only the people who need to respond in a given channel at a specific time, state management to remind people a conversation has not been resolved, and analytics to provide transparency into the level of effort by each person in each channel, responsiveness, full text search and reporting on the substance of historical messages, etc.
> Assume your company is going to be around for 25 years, and treat the first few years accordingly.
This statement makes sense in the smaller context of the point the author is trying to make, but is IMO pretty bad advice taken generally, and it smacks of survivorship bias. It's a good way to overengineer, overplan, and run out of money without delivering much, from my experience.
I got a different take out of it though. I think the author's point is that one has to be more careful with their decisions and choices as the consequence/effect could last a long time (this is where the 25 years assumption comes in), and I could see how this advice applies even in the general sense.
It's different for a consultancy that's revenue-positive very quickly, as opposed to a startup burning VC cash. If you want to build a sustainable lifestyle business as opposed to making an exit, then it requires a different mindset.
> We felt busier, but were getting less real work done
> We knew the clients better personally, but we knew the product less
> We had more superficial conversations, but fewer substantive ones
> We were able to react more quickly, but our responses were less measured and effective
These are very similar to the reasons our company moved from Slack to Google Chat a couple years ago. It was quite liberating.
Edit: In addition to Slack, we also started using Twist (https://twist.com/). We use Google Chat for quick communication, but anything requiring more than a few seconds of thought goes into Twist. So far this has worked really well for us.
Written like a total noob who built their business in a boom and never had to survive an economic downturn. When the next recession, you’ll be begging to be added to your clients slack, IRC, forum, whatever. Hell, you’ll take change orders by fax machine if that’s what it takes to get the PO. GTFO of here with this attitude. If you’re this much of a pain in the ass with something so small, I’d hate to work with you when the fit hits the shan. We ask ALL of our vendors to join our Slack. Don’t like it? Neeexxxxt.
My experiences (with different situations) were nearly the opposite from those described in the article. My previous company (real estate company with a small software development team in house) hired various outside contractors. One was a company that worked on a mobile app, they invited us into a slack channel and it was effective. It worked well with our workflow as we already used Slack for a large part of our engineering communications. We also communicated with them via email and even some regular old phone conversations. Additionally, we hired a devops engineer who we invited into our slack channel and that was effective. Nearly 100% of our communications with him was in Slack. The devops engineer wasn't someone we communicated with on a daily basis but occasionally we messaged him and it worked fine. We also hired a few engineers through Upwork and invited them into some slack channels in our company and again nearly all our communication occurred through those channels. So, our experience of being invited to another company's Slack as well as inviting outside contractors into our slack channels were both positive. Our work is very different than a marketing firm, so I guess everyone can take these anecdotes with a grain of salt.
They say that Slack brought them closer to the clients on a personal level and then they chose to kill it. That's a terrible choice that clearly shows their 25-year priorities are whacked out.
As long as the output is basically acceptable, clients are going to prefer to employ contractors with whom they have strong personal rapport. Making communication difficult and intentionally avoiding the "distraction" of building that relationship is a quick way to die.
Ugh, that sounds awful. I've maxed out at 4, but I only belong to Slack channels for customers that I work with.
I had taken this as a huge plus in my circumstances -- having them separated in their own space per organization allowed me to decide what set of rules I use for replying very quickly vs. when I get a Round Tuit, but that's a very small problem to fix if I had to manage credentials for 15 channels!
It's amazing to me that Slack has been operating this long with such a backwards concept of Organization > User hierarchy. After Apple fixed their portal a few years ago, Slack is the only tool I have left that requires this multiple credentials. It's also frustrating that every time a user leaves an organization, my entire chat history with them is deleted as well.
> It's also frustrating that every time a user leaves an organization, my entire chat history with them is deleted as well.
That may be a setting in the organization or something that your Slack admins are doing? I'm able to look up DM history with former employees in our Slack, their account is just tagged as having been deactived.
> It's also frustrating that every time a user leaves an organization, my entire chat history with them is deleted as well.
Well now that is just incredibly broken - for organizations without a strong culture of documentation, chat/email histories are vital. To just loose conversations sounds painful.
Slack is less than ideal from a customer support perspective due to its extremely limited channel organization tools. I loathe having a blob of 15 customer channels that I'm contractually obligated to be in, but for the most part only have activity once a month or so, if ever.
Stuffing those in a folder a la Discord would be a boon, but the only option that comes close is using a separate organization, which would cost more.
We made the exact same experience (our company is also roughly 3.5 years old). In the beginning it was US who suggested to open a slack because we thought it would help us to resolve questions quickly. However we observed that this only incentivises to have chat discussions over topics that are better discussed and resolved in person/over Skype or via an thoroughly thought through e-mail that cuts straight to the problem.
In addition it added another communication channel we HAD to monitor from that point onwards because our clients had learned from US that we’d respond quickly, so not responding was not an option. This was especially problematic for our developers who would get disrupted way more often. In addition communication was scattered among channels which made it difficult for the PM to stay ahead.
Our lives are easier and our communication with our clients is way more productive ever since we abolished slack.
Should this be considered controversial? I’m not sure what service they offer but if a client asks for someone to join the their slack why would anyone accept unless they were paying someone to monitor it on a full time basis?
Would you do work for free? Nah. This isn’t a slack thing.
This isn't a Slack thing per se, but it is a "direct line of low cost comms to the team" thing, and Slack encourages that. There's an implicit cost to things like face-to-face meetings. You can literally bill for them, so they don't happen very often (relatively speaking). By using a chat app you can bombard a team with requests for free, and there's an expectation that they're not going to push back because the 'real time' nature of it means they won't have time to carefully consider a negative response. It's much easier just to say yes, so teams do. A lot of clients abuse that.
Managing clients is hard, and it's a real problem.
This makes a lot more sense when the company and contracts involved are big enough that you don't /have/ to bill because a support or customer liaison / requirements solicitor gets included as a full time position as part of the contract.
The implication also being that they act as the filter that's often missing on such "low cost" communications.
This. In my experience: if "joining slack" means you spend a lot of time chatting about random things and get to know the people privately, you're not doing your job and the work culture is a red flag. I've seen people do the same via email, where they quickly spiral out of work and end up sending each other pics of their pets all day. I don't think it's a medium thing, it's a people thing.
I actually fully understand this situation. If you build stuff you want to reduce communication channels and keep it lean, otherwise you get a lot of distraction about mostly superficial and insubstantial matters. Important things will happen there too, of course, but you prefer to have a controlled ways of communication (e.g. something that works in your team). Sometimes it’s good to shorten some communication paths and directly reach relevant people. But in the longer term you want to avoid it. Otherwise you will have your devs being contacted from other different people and it will create a lot of communication mess. You want to secure your people from such noisy communication.
Wouldn't a solution be to have a public slack channel that your customers can join? SparkPost does this and it has been quite helpful to me as a customer, without the overhead of SparkPost having requests to join hundreds of client slack channels.
My background is in hanging around 100+ IRC channels which is probably why I never have felt Slack distracting a bit. I have notifications on for only direct @s and I can postpone any interactions accordinly when needed.
Compared to that emails (and Basecamps and such) feel anxious: tens and tens of different information cramped in a long form text and the expectation us to handle all of them at once and as soon as possible, after all it’s email.
And then again I know of people that have it completely other way around and I understand that. I also think that there’s no solution for that in software form, but in behaviour: we need to embrace the asyncronisity.
I think Slack/IM is a great tool, but maybe not for "deep" engineering work and requirements discussion. For things like this it is more important to have some structure and documentation behind it. As mentioned in the article Trello works well, I personally like Wrike but anything written down in one place is good!
Where Slack helps me the most is asking my group questions which seem too small for an email, like "hey what is maximum RPM of the motor we are using?" where anyone could respond and also other people can benefit from the answer.
> Where Slack helps me the most is asking my group questions which seem too small for an email, like "hey what is maximum RPM of the motor we are using?"
That's interesting, because I view this exactly the other way around -- an IM is like a phone call, in that if someone is sending one, it's because they have an urgent need and are expecting an immediate response. Email is for the lower-priority things.
This is not really any different than customers clamoring to get the direct email/phone # of developers instead of going through the normal tech support process, or to clamor for daily meetings/phonecalls/sessions.
Slack might just be worse by degree.
I hate all of the above often having to "support" Tech Support.
I have often wanted to tell a customer, "We will not make progress on this till we stop updating you on progress every 5 minutes."
This stuff is even worse when you have an army of internal "Customer Success" types at a big company.
I used to work for a digital consultancy, one of the projects I worked on had a shared slack team between the client and my company. It definitely created problems, but IMO, the problems were because there weren't limits or understanding around how slack should have been used. The staffing of the project changed pretty significantly throughout the years I worked on it and the trouble came from not setting expectations around how slack (and channels) should be used.
I never even considered that people would add clients to Slack. We don't even have all our consultants on Slack. We use it as a purely internal message board to communicate short thoughts, updates, publishing reports, maybe ask for an impromptu meeting etc. External communication is almost all by email, phone, or Zoom.
That said the 25 year rule is absurd. Who really thinks Slack is going to exist in 25 years? Netscape was just founded 25 years ago.
I agree that Slack can pull me out of the zone. Also it's terrible when you're trying to find a decision your team made in the past.
I tried Twist but couldn't get any buy in from the team. Seems like it would solve the issues I have with Slack: it has real-time chatting, but also long-term async storage. It's also easy to move a conversation from the real-time chat to the long-term storage thing.
Noisy notifications is NOT inherently a Slack issue - slack is just a communication platform; it is however a company culture /team culture/communication style. Fix that instead, Slack is just a tool, it also has controls of muting notifications as many others mentioned here.
Something they didn't mention is that joining would not at all be a sustainable course of action. You'd end up having to join for all of your customers, or at least all of them that use slack and thought to ask.
I have a bit of a different take on this. Personally speaking, I've only been a Slack user for 2 years. Prior to that, I lived out of Skype for Business (now Teams[0]).
On one hand, I've had each of the issues he lists in his bullet points when dealing with Slack (though we only ever join customer's Slack channels), though I've adapted my approach and it's been minimal-to-non-issue, lately -- and I've got no customers asking for this at this very moment. The thing is -- I do not and have not had these problems on Teams.
I believe these sorts of problems aren't general problems that messaging applications introduce, but are problems Slack doesn't handle well. At first, my thinking was "everyone can have it, so it's like the old days of AIM, except people use this for business and a lot of businesses use it", so I went to "it's a public form of AIM that corporations are asking employees to use". None of that is particularly accurate, and it ignored the fact that every OCS - Teams installation that I've used had been federated with people I worked without outside of my organization. Slack didn't really "mainstream" this sort of thing with the people I worked with, so why do people on Slack behave differently?
The only reason I can guess is "Status". Microsoft always pushed this as a huge selling point to their product and I remember thinking "that's dumb" for the first several iterations, but right around the Lync time-frame, I realized that it created a behavior change in me. We used OCS for everything, including telephony, so when someone had a meeting blocked out in their calendar, or was using their phone, their status said "In a call" or "In a meeting" and was bright red. When you shared your screen, your status went do not disturbt[1]. Screensaver pops up and your status goes yellow "Away". You can also set these statuses, manually (which was rarely abused at the 3 shops I was at).
Another important factor was that chats were not persistent[2]. This changed with Teams, and the jury is still out as to how this impacts things, but I think it will make the specific bullet points he mentions worse. In general, when I would send someone a message on Teams, I'd not expect an immediate reply -- even if their status was green -- and if I didn't get a reply, I'd follow up with another method of communication. The idea was to avoid a phone call for something easy. Yes, this eliminates a lot of the "personal hands-on sort of interactivity" that a phone call grants, but it also eliminates 10 minutes of talking about spouses/families when you and I are in the middle of 3 other things and aren't terribly interested in keeping up with cultural norms.
Because status gave me enough information to answer the questions (1) "Are they likely to respond?" and (2) "Am I likely to interrupt them?". I did a lot of development for this platform and I had a ~15,000 person installation to get stats from -- it's interesting to see who had "status change alerts" setup for whom, when they'd be turned on/off, how often people would set their own statuses vs. using the one automatically set. It worked about as I described; replies fell off when statuses were not green, follow-up phone calls frequently followed unanswered chats -- all of this data was relatively easy to grab out of the massive set of SQL databases that powered the whole thing on-prem.
Contrast that with Slack. Unfortunately, at my new employer, we use Slack and are migrating to Teams, online, so I can't get stats like that any longer and my only visibility is myself and my immediate coworkers. There are, effectively, three/(four?) -- mostly worthless -- statuses, some of which behave in a manner that contradicts the features they provide:
(1) Zzzz - it's before or after work; useful when I need to reach out to folks in Seattle and I forget how to subtract by 3. Otherwise, as useful as a clock or my own two eyes looking at the desks nearby. And why warn me not to send this message? You're going to keep it there until they wake up and look, so how about just warn me that you're not going to notify them because they've snoozed alarms, but that the message will be waiting for them when they return?
(2) Offline - grey circle - they're not there or left, or maybe they went to screen-saver or their client as acting up. The thing is, I rely on status so minimally that I can't remember if there are two to cover Offline and Away. Both mean "don't bother" even though they shouldn't -- they're saving my history (if I'm paying, but even if I'm not ... for at least a few hours!)
(3) Online - green, solid, circle - they might answer me.
In addition to that, you can set an icon with a secret (/s) message. I say "secret" because nobody ever sees or reads it. I set mine last week to a "BIG RED STOP SIGN" with a message indicating that I was focused solely on a single project and in the middle of a crunch. I've been done with that for a few days; I received more messages about other projects I had to table last week than any other time working here and this message was so noticeable that I didn't even remember to turn it off until I looked at it just now for the purpose of this post.
So people message more. And they still follow up with phone calls and e-mail, just like they did before, but the messages are reaching their audience less frequently. When people at my last employer sent messages on Teams (Lync at the time), it was 85-90% targeted at "Available" and "In a meeting[3]". I'd bet it's the same way now, only "Available" covers a whole lot of time when nobody is available, causing more messages, less success and more frustration with the product
[0] To be accurate: I lived out of Office Communications Server (OCS), OCS R2, Lync, Skype for Business (and all of the CUs in between) -- I used to develop for these platforms so I was an early adopter.
[1] So intelligent -- never have someone send you a sarcastic or embarrassing comment while you're sharing your screen.
[2] Not, strictly, true and not true at all with Teams. If administrators enabled the capability, chats were stored in your e-mail box where they might as well have been deleted. Group Chat behaved exactly the opposite -- you had to install a massive client and all chat logs were kept forever with no way to delete them IIRC. Very few actually used this product. Teams behaves more like Slack but with all of the capabilities of Skype for Business.
[3] This was puzzling; we assume it was because the vast majority of meetings were conference calls after full adoption of OCS R2, so "In a meeting" meant "I have a meeting on my calendar that got cancelled" or "I have a very rare, in person meeting with only people in the office", otherwise it said "In a call". So really, it became "Extra Available" since you had time blocked out that freed up.
That comment got away from me in length, so to summarize:
I've been an add-on developer for Microsoft's competing product since the TAP (beta) program for OCS and part of a few organizations who used it as their only telephony/messaging product but people used that product differently.
As part of a project between the two TAP programs, I wrote a dashboard site that provided stats about the operation of the on-prem installation, mostly centered around telephony, but included a lot of information about who was "tagging users for status change alerts" (without details, just rolled-up), IM-only conversations (this was tricky) and stats about interruption with regard to user's status. My personal experience was that we communicated more frequently via IM and had fewer "missed connections" on Teams, resulting in fewer escalations to less convenient forms of communication (and less of a feeling of being ignored). It is my belief that this happened because Teams provided rich information about the status of the user (and also didn't keep IMs around so you didn't expect them to follow-up later if they didn't reply in a few minutes).
Unfortunately, I have no such insight into Slack's back-end, but anecdotally, I am interrupted far more through Slack than I was in Teams and my messages go unanswered far more often to the point that in Teams where I positively relied on status before sending a message, I don't even look at it in Slack because it doesn't help me to decide whether or not I'll be better off picking up the phone or e-mailing.
and so, a company can set statuses that staff can be required to pick from, perhaps some common ones like:
- In the office
- Working from home
- In a meeting
- PTO
and the company can then make it known to staff that their status icon should accurately reflect their current work ... status, and not whatever cute emoji they want to use.
DND/Do Not Disturb should not affect use of Slack status. Force the notification through if your message is urgent.
this is not rocket science.
if Slack usage is affecting how a company works because staff can't tell if someone will respond or not -- change the way the staff use Slack to better suit the business.
You make fair points and I'll be the first to say that my experience (and preference) lies elsewhere, so I'll explore the links on Monday to see if they make life easier.
The major point that I didn't make clear enough about statuses "not working" is that even if there were more statuses, they are manual. We observed that people manually changed their status, most often, to "Available" from another non-available status, under Skype for Business. Outside of that, people simply didn't manually manipulate their status. And when they did, they'd often leave it that way for a ridiculously long time because they'd simply "forget".
Inadequate status choices are not as bad as completely unreliable statuses. Teams shined in providing enough status about a user, automatically, for a non-developer, non-technical user to reliably answer the question "Will I get an answer to my IM/call when I send it?" and "Is my IM/call highly likely to be an interruption?".
If you used it for telephony, or had the Skype for Business mobile client installed, you switched to "In a call" when you were on the phone, "In a conference" when you joined a Skype for Business conference call, "Do not disturb - Sharing" when you started screen sharing (and it kept inbound messages from showing up on-screen for your audience). Honestly, it seems like one of those under-the-fold bullet point features, but it is its most important.
In the scenario you talk about, above, two things have to happen (after configuration is altered to allow changing statuses). The user has to regularly change their status to signal their availability (not physical presence or time of day, but "I am busy doing something that should keep me from responding"). And the rest of the users have to rely on that status. The only way that happens is if the status is accurate far more often than it is wrong. That won't happen unless everyone is rigorous with making status changes... and that's not a memo I want to send.
Lync/Skype for Business (and I assume Teams) gives you both options. Let it run automatically and it'll switch your status when you receive/make a call, join a conference or have a meeting time blocked out in your calendar for you and put it back when you're done, or set it to what you want. And you could extend this capability[0] and automate it in different ways.
[0] The old on-prem version was insanely customizable; you could completely re-implement the client, they provided every hook required to re-implement dial-in conferencing (an "Enterprise" feature) in Standard edition (and actively assisted in a project I worked to do just that).
Never used a chat client for anything other than work. Not sure why that's so difficult.
Not to mention, chatting with people usually means they treat any request you have as low priority. Whereas going to them elevates that priority substantially.
I see people at my office (and different companies!) saying they quit Slack/Whatever because they were getting bombarded by notifications... They had the option to notify on all messages. ¬¬
Even then, come on, I cannot believe experience hasn’t taught most of you how to handle quick interruptions. I usually just quick look at the notification to see if it’s really urgent. Otherwise it may be 7-10 minutes until I actually check the application, in case I’m doing some heavy thinking/coding session.
There are true interruptions like constant notifications, people physically talking to you about other things, and stuff, that while you cannot really tune them all out, you should be able to handle better with 2-3 years of experience. I read a lot of people on these forums with many more years not being able to cope with that.
I will die still unable to believe it was the norm, and not the exception :(