How Big Technical Changes Happen at Slack
slack.engineering
slack.engineering
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 user from the account, i.e. the same user has different rights depending on the account he is using.
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.
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.
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.
a) People who hate Slack
b) People who hate open-plan offices
c) People who can't imagine why anyone would ever have a different opinion than them on such topics
In my company, everyone can work from home or gets own office. Period
Code snippets: Slack does not allow you to type put highlighted code snippet in a middle of a message (you must import them in a separate message).
Code Snippets: If you import code snippets using the tool, you cannot simply copy paste from it. There will be extra new lines and other noise.
Links: Slack does not allow you to put a hyperlink except verbatim.
I’m sure there are more. But slack is a pretty lousy chat client with poor support for basic needs of developers of code.
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.
```diff
- Remove this line
+ Add this line
```
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 ```` ``` ````).
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).
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 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.
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.
Also the free model is _very_ generous.
Exactly. Slack's biggest benefit was "chat with persistent history, the ability to message offline people, and notifications". That's table stakes now.
And they had emojis.
HipChat was god awful. It was half assed in almost every way (especially the mobile app). Atlassian simply didn't see the opportunity.
Slack was leagues better. It was as simple as that.
https://www.atlassian.com/blog/archives/hipchats-terms-servi...
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.
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 only features they work on are the next-gen features while the more comprehensible login flow wouldn’t get you a promotion.
> 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 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.
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.
+---------+--------+---------+---------+---------+
| |ttm |1/30/2019|1/30/2018|1/30/2017|
+---------+--------+---------+---------+---------+
|Operating|-540,530|-154,208 |-143,851 |-148,503 |
|Income or| | | | |
|Loss | | | | |
+---------+--------+---------+---------+---------+Slack got that right. It’s not perfect, but it was a major upgrade.
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.
Preferences > Advanced > Format messages with markup
Drafts seems to also be universally despised, but they haven't yet done anything about it
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?
That’s a highly disturbing and misguided framework if you ask me.
The point is that a baby is a being with potential - and require outside input to reach that potential.
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.
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 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.
Suboptimal code might have something to do with it as well, though.
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:
https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor...
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...
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
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'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.
Most startups never see the effects of their bad (or good) choices because they go out of business.
Good choices too, for that matter. They tend to live until they turn into bad ones.
M&A guy here. Sure, this is nice, but the answer is pretty much no.
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
- ORBs turned into microservices
- Neural Nets turned into Deep Learning
https://mirage.io/ https://www.redox-os.org/
Don't microkernels have a real shot at replacing containers? Maybe we can stop running the huge linux kernel for every microservice?
Ehm that's exactly how containers DON'T work. They share the kernel... (and only the kernel)
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 ...
And people still sometimes use non-deep neural networks because depth can increase overfitting.
It's nice to see a company factoring in the evolution of technology in their product, for a change.
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.
As someone who uses #1 and #3 every day, I wonder what it is like coding in the 21st century :/
But we use CORBA a fair amount, kind of almost as an abstraction layer on top of QNX message passing.
(been working with a custom in-house RTOS for the past few years...)
(but I do not miss QNX's build system. Recursive makefiles!?)
> The vmkernel is a microkernel[13] with three interfaces: hardware, guest systems, and the service console (Console OS).
Uh... What about Zircon[1]? It powers Google's new mobile operating system: Fuchsia[2].
And at the same time it is a great commercial success. This last one I cannot understand.