Slack is one of those few platforms, where their success makes no sense to me at all. I hate using it, I hated their bloated desktop apps, I hate the separate passwords/emails for every location you log into. I hope to one day understand the magic behind Slack, Salesforce, Sitecore and a few other huge tech successes, that have subpar tech.
You don't see the magic behind Slack, because it got lost.
At one point in the past Slack was new and shiny. It had much less features, but every one of them were crafted with UX in mind. People were raving about it, because for many it was the first time they could use something that had the nice properties of IRC chatrooms, in a nicely polished package, and it was usable in a work setting. It brought some fun back into the workplace where you previously had boring email inboxes.
I don't know exactly what changed. Maybe with feature bloat, the same care for UX was lost. Maybe the competition caught up and it doesn't stick out as that special anymore.
> Maybe the competition caught up and it doesn't stick out as that special anymore.
Exactly. Slack's biggest benefit was "chat with persistent history, the ability to message offline people, and notifications". That's table stakes now.
IMO the main reason Slack became successful is the massive number of pre-built integrations that were (and still are) available even on the free tier. It meant that you could use it as a message/log/notification aggregator for the various pieces of software you were already using. Furthermore, those messages/logs/notifications immediately became searchable so you could for example do a search for <customer name> and have ALL the stuff related to that customer show up in the results (with links to the source applications).
That's not how I remember it. I remember Slack being more or less functionally identical to HipChat, but HipChat had some PR disaster about their privacy policy that spooked the valley and "switch to Slack" became the wisdom of the day.
Na, they did. They put everything in to Hip Chat, even attempted a re-write which led to Stride, it's replacement.
Check the logos on the bottom https://www.pubnub.com/what-we-do/. The core part of any chat client is? messaging. Outsourcing your core layer, hmm...
Something must of gone drastically wrong somewhere from having it as the #1 business priority and beating Slack to instead selling their customers to Slack.
That's not true. They absolutely did not. Not soon enough.
Slack launched in August 2013.
Stride was release in September 2017.
But then it was way, way too late. 4 years is an eternity. Even Microsoft Teams had come out before Stride (in early 2017).
Slack would go public less than 2 years after Hipchat/Teams launched with $400mm in revenue (FY2019). To give you a sense of Slack's scale and some perspective, the same year Slack went public - Atlassian did $1.2B in revenue.
The world is not that black and white. I hate open offices but still love Slack and accept opinions of others. I think there is not much correlation between a, b and c.
> A large majority of people who use Slack disagree with you
How do you know? Most people I know, uses Slack because that's the company policy, not because they find Slack the best option. But I don't think that's the majority of people, because is just my biased view, but probably it's the same in your case.
> I have... never met anyone in real life who doesn't like slack. I only hear negative opinions about it here.
While I have literal never discussed Slack with someone who likes it. Actually not completely true: at my last company one developer thought it was great but after a few months I heard her curse it as a "place information goes to die". In my experience it doesn't scale beyond a very small number of people who know each other well. Sending commands from its command line is not as easy as simply sending them from, you know, the command line (which is scriptable).
As a side point it astonishes me that after all the money they raised and people they hired they can't get video working on mobile, just laptop/desktop.
I love Slack. It’s also where information goes to die. You’re not supposed to keep permanent info in a chat room.
You could say the same thing about meetings — they’re where information goes to die. Because a meeting (which is what Slack is) isn’t meant to store information, it’s meant to discuss information.
Come grab a coffee with me, I'm at 2nd and Howard, about a block away from the Slack office. Or just hang near the sidewalk, our windows are open and at some point my whinging about slack (or gitlab) should float down to the sidewalk.
Counter point: I've used Slack at several jobs and in several other group settings, and never met somebody who loved it. People like that they can message groups, separate threads into channels, but Slack the client feels like very slick enterprise software at best. (Contrast cases in the chat/productivity space: Discord, Telegram, Notion, Airtable, Coda)
It's crazy to remember as recently as like 2013 the company I was at used a jabber chat server. The recommended client was an open source, very barebones one with no design whatsoever. There was no searching through history other than the messages that had already been downloaded to you device, no mobile app, no images. Most people just used gchat instead even though that was discouraged, but the company group rooms were on the jabber chat so everyone had to use it somewhat.
Even then it felt pretty dated, but the infrastructure team that ran it thought it was good enough so we kept it. Hipchat was a thing that was clearly better, I remember talk about it and I think some people pushed to switch to it, but it seemed like a daunting task and not all that important so it never happened.
Then not too long after that, Slack had come out and one day I just happened to notice that the frontend team was chatting on a new app. I'm sure there were some frustrated conversations between them and the security team, we were big enough that we had a couple person security team and had some rules about only using approved software, but I guess not big enough that there were going to be any strict repercussions for breaking those rules. And that was that, a few more teams started using it, and at some point enough teams had it that we just officially switched.
Between search and multi-client use it was clearly better than our corporate chat. The design made it more enjoyable to use. But the real killer feature was the low barrier to entry, I think it snuck into a lot of organizations in exactly this way by having a generous free plan and a web client so that anyone could just start using it without asking permission.
Before Slack, my company used HipChat. I would routinely not receive notifications or messages on mobile, or receive duplicate notifications or messages on multiple devices.
Slack got that right. It’s not perfect, but it was a major upgrade.
Counterpoint, for the last few months when someone starts a 1:1 call with me, after I answer it it keeps ringing on my phone. Also, it has a persistent habit of my phone showing an "unread messages" notice, when I'm literally sitting at my laptop and have everything read.
A few reasons. First is that developer's don't buy it, non-technicals do, and it's got serious vendor lock-in capability. The other reason is that an excel-formula-wizard-type user can basically google his/her way to building a CRUD app for the business - and it works for the most part. Those combined are a billion dollar company. Us developers might not like it, but it has huge business value one way or another.
I was on the train from Boston to New York one time, and a bunch of Salesforce employees (sales) were also in my car. Let me first say their sales team is relentless and never gives up. However, at one point they were speaking with a prospect about various integrations. It went something like:
> Sales Guy 1: "Is integration X available? Let me check. I luckily happen to be sitting next to one of our integration developers. Let me put you on hold for a brief moment."
> Sales Guy 1: "This wanker thinks he'll get the Ameritrade integration for free. We have that, right? What should I charge him?"
> Sales Guy 2: "Yeah. Just tell him you spoke with your developer, and that the integration is custom, and will take some development time. Keep him on hold for a second to make it seem like you are working for him."
> Sales Guy 1: (Eventually) "Thank you so much for your patience. I spoke with our developer. It's a tough integration and requires custom work, so it'll be an extra 12k. I hope you understand..."
I do agree with some of your rant, but actually the separate passwords/emails for every location are a very clean implementation of multi tenant client login.
I'm not sure how well it is implemented in the backend, but if it is safely separated in the database while having the current UX it's actually really well designed.
A "clean" multi tenant login separates the person from the account. There's no reason for a person to have a direct 1:1 mapping with a system user or account.
This is why I don't personally understand all the Slack hate. It's a godsend compared to every other messaging service I've seen in an enterprise environment. I'm stuck using Webex Teams right now and it's horrifyingly bad.
Being better than [x] does not make Slack good, per se. It might make some thankful they aren't using [x], but that's really about as far as that should go.
I like Slack more than Skype, but I hate Slack with the passion of 1000 firey suns, especially in regard to many UIUX decisions. (Why does the new message line stay on the view AFTER I HAVE RESPONDED?) Not to mention the un...helpfulness (I guess) of their support.
Slack was great when it was new, because it was better in someway than everything else out there. Mind you not the same way for everything, but in some way it was better than most, if not all other options avaliable at the time.
That is not the case now. There are other options that are as good, or better. Slack MUST have been aiming for that 'fuck-you' size the entire time, because once they hit critical mass, they seemingly immediately stopped trying to be better, and started trying to be the one you were already paying; a serious downgrade in my opinion.
It isn't terribly popular, but Zoho's Cliq is pretty much a clone. There's a few things it doesn't do as well, and others things that I actually prefer (multiple channels on screen, for example)
I'm a coder and have been using slack for years with success. Not one single one of your complaints has ever been an issue for me.
Whenever I want to post a code snippet, I just use the triple backtick technique, like:
```
code goes here
```
You can also insert code in the middle of a comment with a single backtick around it: `like so`
For the most part, though, I keep my code in the Git repository, and it's pretty rare that I actually need to share a bunch of code in Slack messages. If I want to pair with another developer I just open up Tuple or Zoom and do a screen share.
Syntax highlighting in a message is really powerful if your message includes a series of diffs.
```diff
- Remove this line
+ Add this line
```
But even if developers are fine with highlighted code snippets inside message, that still leaves the buggy snippet tool which adds newlines when you copy-paste from it, not enumerated, or bulleted lists, no hyperlinks except verbatim, etc. The no hyperlink part is annoying if you have to link a couple or more long urls and placement matters.
Edit: To add to the list, since slack doesn’t use real markdown it is impossible to included backticks in code samples (e.g. `` ` `` is not a thing, and neither is ```` ``` ````).
Yeah if I feel like my snippet could benefit from syntax highlighting I’m probably doing it wrong. I can’t imagine other people would appreciate my giant walls of text/code in a chat channel. I can use a gist, screen share or link to a specific line in a repo if I need to.
Email. With per-topic mailing list server (that is: send a message to whoever you like and cc the list). Self-subscribe (with approval for sensitive topics) for any email list. Archive to a threaded web-based archiver. Search-index it.
Everything you need: High speed communications. Long-form, if you need it. Only getting notified about things you care about. Written discussions about things like how design or business plan decisions were made to be perused at leasure by new hires in the future (Knowlege-base).
For a company that got going for being better than email, it's shocking to me how email (done correctly) is still better on almost every dimension (except asking what people want for lunch).
Completely and utterly disagee. I'm not even a big fan of slack, but email is -terrible-. I can't tell you how many lists I'm on now where someone poses a question and 50 people all reply all with the same thing. And that's not counting the people who probably started a reply then saw the flurry and didn't send, or the people who replied privately. That's one huge benefit to slack in well organized channels. You pose a question to a group, and generally if one person starts typing, you wait to see if your reply is needed.
In my case, for one, the engineering orgs were generally not much larger than 200 people. For another, the "To:" person(s) usually responded, but everyone else got cc'd with the list and then the list could follow. And, for me, finally: I find discoverability in a knowledge-base-way to be sub-optimal compared to an indexed (and threaded!) email list. Kind of like how Linux devs organize themselves.
And, maybe, finally, I'm old and have been using email since 1983 and it fits my workflow (or rather: my workflow adapted to email?). The get-to-it-or-it-is-gone thing with #slack bothers me, which seems great for asking people what they want me to bring back for lunch, but not for much else besides asking who broke the build.
Again - that's my take. I understand that other people don't prefer long-form debates/discussions by email and want an IRC-like answer to their immediate question.
I despise some Slack features. The drafts folder and the wysiwyg editor. I’m still happy to use it overall, it’s a huge step up from Skype for Business.
Just use the same password for all of your slacks? It's not like they're going into a different database... If Slack gets breached, all passwords get leaked.
Well I also don’t understand, I have not used slack and don’t intend to use one either. It’s much worse and proprietary interface, I am happy with IRC and it’s support in emacs with ERC.
I just can’t understand many open source project force users to use it. I can understand JavaScript and web development crowd vying to get on slack given the kind of IDE and tools, they use.
I cannot bear the slow speed with which slack works compared to IRC in terminal, emacs or VI.
What I mean is not used in any of my projects or work. I have accessed it when working on Elm, and after loading it once cannot even understand why Elm a language which wants 0 runtime error in JavaScript can even accept such a slow system. Even if Elm wanted wanted a web user interface on top of IRC, they could have gone with discord app (although personally I still prefer IRC), which is far far ahead of slack when it comes to quality, latency and works much faster.
But doesn't matter in a hurry to replace e-mail with something different companies are choosing much worse solution like Slack. Email, IRC are very good. Slack is a product of spending millions on advertising and marketing and be loss making for as long as possible and than list it to let it gamble on stock exchange or get acquired by bigger company.
> we are ruthless in killing experiments early that do not prove valuable.
Ed Catmull of Pixar calls new ideas "ugly babies." Ugly because they're covered in warts -- aspects that are easy to change, but that doubters seize on because they destroy value. For example, the script for the first Bond film, Dr. No, had an intelligent monkey for a villain. Babies because they don't have value in their current form, they need more work and iteration before they have value.
How does slack identify technologies that don't have value now, but whose problems are superficial and fixable?
One example of Slack's decision making process is discussed in Jake Knapp's Sprint book. Essentially, create rapid disposable prototypes and test on real people to address specific problems.
I very much disagree with the fads vs. revolutions division in this article, or rather - I find it unfair. A certain technology succeeding often has a lot to do with its quality, but it's impossible to ignore all the complex social processes happening around it.
Sometimes great solutions simply arrive at a bad time, or don't have proper funding, or marketing, etc. It definitely makes sense to be on the lookout and try to improve your chances of identifying the winner early on for business reasons, but that doesn't mean the winner is always the best.
Once you're as big as Slack, you might even be actively harming others by doing that - i.e. a better but less popular technology might have won in the end, had they backed it.
I can't fathom why slack is so slow, on MacOS i see a channel that is white, new messages await. I click it, and honest to God sometimes seconds pass while slack loads the _text_.
How can this be? How could my slack client with a 30 Mbps connection have received the signal that there was a new message but also not downloaded the few bytes of text as well. Maybe it did but a MacBook pro from 2018 takes seconds to render text? AOL or MSN didn't back in the day.
The trade off between packaging a html/css website as a standalone app in it's own standalone web browser minus toolbar vs apps using native toolkits such as AOL or MSN.
It's very easy to make a nice application with Electron, but very hard to make one that actually is large and compatible.
I mean the system requirements for AOL Instant messenger in 2008 was 300 MHz CPU, 256 RAM, and 250MB of hd space. Compare that to Slack - they don't list the system requirements but I am sure you all know it probably demands at least 1gb of RAM and will use all of it:
Let's face it we are reaching a new dark-age of computer programming away from static typing and caring about performance to a hellscape of ECMA script...
I think the problem with basing anything off of Electron is that the stack is just too daym high and depends on so many things out of your control. Not to mention Google owns you and your application and could add stuff to Chrome that snoops on your users...
It becomes impossible for you to do any sort of quality - even making the original choice to use it means you care about the perceived "convenience" of using CSS and ECMA over performance.
> Server-side, we’ve been migrating from PHP to Hack since 2016
A 3+ year migration of the bulk of your codebase is sort of intense. Though the Hack team at Facebook has made some great tools to ease migration, their fairly aggressive sunsetting of PHP features in Hack has presumably made this job a little harder.
Also notable: Slack is the only equivalent company (outside of Facebook) that uses Hack, at least that I know of. I wonder if that makes Slack a more likely acquisition target.
I predict the next Chief Architect will stall (or begin a rollback of) HHVM at Slack. Too much time wasted migrating onto a nigh-proprietary platform for a now ambiguous value proposition.
He also once wrote an article citing concurrency as a benefit of PHP and advocated services making web requests to themselves as a good way of achieving that. How that was taken seriously, I will never know.
To be fair the bad choices are what allowed them to ship quickly, get to product-market fit, and get to the point where the bad choices started to hurt them.
Most startups never see the effects of their bad (or good) choices because they go out of business.
Not really a comparable company. Quizlet has <100 employees and $32M funding. Slack has <5000 employees and has a $15B market cap on the public market.
I'm sure there are a ton of small-ish VC-funded startups using all sorts of technologies like Hack. As far as big companies though, FB and Slack are pretty much it.
True. My understanding is that they're fairly active in the Hacklang community; they're big enough to have received a mention in the HHVM docs: https://docs.hhvm.com/hhvm/FAQ/faq
> Microkernels; EPIC architectures like IA-64; object request brokers; and 1990s’-style neural nets are gone, and will not return.
I am not entirely convinced that they are gone:
- Xen is essentially a modern microkernel. The most popular "microkernel" from the 1980s, Mach/BSD, evolved into Xnu/Darwin which powers macOS and iOS. L4 and other microkernels still exist.
- VLIW lives on inside GPUs as well as x86-compatible CPUs
I don’t hate slack but I’ll share my least favorite parts In the hope someone will see these good ideas and fix them
1. The rich text editor (thankfully you can turn it off — I am very sad for non savvy users who don’t know this)
2. The UX of snippets - I paste something long into a code fence — fine its too big and you need to send it very a different mechanism — just di that please don’t ask me and make me click around - ideally you’d see the big text blob inside the code snippets and just extract those into something the reader on the other side can click - this way I can provide exposition and give the reader the option to get more details if I’ve convinced them there’s something they should look at. Present options all require me to either lose formatting of my exposition or manually copy stuff out if the message and into one or more snippets
3. Link unfurling - yes I can turn it off for me but the readers not for readers on the other side ... they are less likely to engage properly with what I write because of this crap and I can’t fix it for them ... would be great if I can turn it off for messages I send and receive ...
This is a great policy. I appreciate that they provide a roadmap for engineers to propose and explore technologies, as opposed to most places (in my experience) that have a blanket diktat of the allowed technologies, and any evolution has to happen in the shadows, guerrila-style.
It's nice to see a company factoring in the evolution of technology in their product, for a change.
> The new type annotations also caused some problems along with the bugs they were catching, and a canonical static vs. dynamic typing debate unfolded and ran its course. Through debates and accumulating experience, a rough consensus emerged that increasing type coverage would do more good than harm, and a majority of teams elected to use types.
I went through the exact same thing (word-by-word) at my last team and we came to the same consensus.
I caught a bug in our custom made static type checker for Python and argued that all type annotations should be dropped :D but they argued that there are more benefits, mostly because it is easier to understand code in isolation so we kept it and invested in even more type-annotation throughout the whole code base.
Ironacally, Slack IS using at least couple of fads on a product-defining level: Hack is dead by PHP 7 and PHP 8 will dance on it's grave this year. Electron is awful when used atop of big JS framework-based apps (it is more or less okay with nicely crafted Vanilla JS).
And at the same time it is a great commercial success. This last one I cannot understand.
Commercial success has little to do with your tech stack choices. I don't understand why people are so obsessed with jumping ship for the latest shitty framework just as the old one is getting really good and stable.
