3 ms·

without seeing numbers you don’t know whether it’s good or not for them, it’s possible that they get plenty of growth through these channels

by buryat 5y ago

submeta 5y ago
At what cost? If growth means the platform cannot handle the traffic properly, you’ll loose users.
- steve_adams_86 5y ago
  Agreed, it's definitely how they lost us.
steve_adams_86 5y ago
I think the point about performance seems relevant in my experience. This is a problem Slite seems to be facing as well. We used both for a while and actually gave their teams a lot of feedback. They were very grateful and communicated well, but moved very slowly and performance decreased quite a bit over time. We ended up focusing most of our planning/note taking/scheduling efforts in Linear instead. Much, much different but it works well enough while remaining extremely speedy and productive. I do miss a lot of what documents had to offer our team. I don't miss fiddling around with slow documents which didn't offer all of what we needed (and might never offer it). I'm not sure why but most document-based apps like this seem to develop terrible performance. I suspect it's genuinely a difficult problem; I don't think I can 'make Notion in a weekend' by any means, or Slite for that matter. I trust they're doing their best. I also know these tools suit some teams incredibly well, too.
- polote 5y ago
  Honestly I think this is because Notion, Slite are mostly frontend apps at the core. And thus attract talents who are strong in frontend, and the culture is biased toward front end (actually in Notion it is even biased toward UI). And thus they neglect backend due to their culture which leads to performance issues. I agree that you can't do Notion in a weekend, I have been working on something similar and it took me 8 months full time to have something that starts to look ok. But that's also why I'm not bearish on having good performance in that kind of app. Notion made very dubious choices regarding their data model which explains why it is slow. Slite did not, but I thought that Slite had better performance though
- lming 5y ago
  You are absolutely right that building a performant rich-text-editor for large document is indeed a very difficult problem. Mixing real-time collaboration put further challenges on api design and server processing. It's a whole different level of engineering challenges compare to building a performant CRUD web app... I am wondering how your team does note taking in Linear - are you guys create one issue for each document? It doesn't support collaborative editing, right?
  - steve_adams_86 5y ago
    I should have been clearer. We essentially abandoned note taking and began storing all of our tasks in linear in a more granular way. We also all began participating in our issue management more, as it became sort of like the core of project management for us. Looking at linear can give you a very clear picture of where the team is right now, what we’ve been doing, and even what we will be doing. Our issues are a place where we discuss implementation decisions, relate issues together in various ways to provide more clarity, link to external resources relevant to issues, and we organize them into projects and cycles as well. The goal was to convert a process we already used into a more robust and useful process which might make note taking redundant. It has mostly worked. Since we work in software and we’re a small team that’s intimately familiar with most of our code (or at least what the code does), tooling and practices like version control, idiomatic naming conventions, and supplemental commenting in code can helpfully serve as sufficient documentation for the team right now. It’s a much different thing from real-time collaborative documents though and I do worry that as we grow, it won’t benefit less technical roles we’ll need to support the team. That’s where something like Notion becomes very compelling to me.

without seeing numbers you don’t know whether it’s good or not for them, it’s possible that they get plenty of growth through these channels

by buryat 5y ago

without seeing numbers you don’t know whether it’s good or not for them, it’s possible that they get plenty of growth through these channels

submeta 5y ago

At what cost? If growth means the platform cannot handle the traffic properly, you’ll loose users.

steve_adams_86 5y ago
Agreed, it's definitely how they lost us.

steve_adams_86 5y ago

I think the point about performance seems relevant in my experience. This is a problem Slite seems to be facing as well. We used both for a while and actually gave their teams a lot of feedback. They were very grateful and communicated well, but moved very slowly and performance decreased quite a bit over time. We ended up focusing most of our planning/note taking/scheduling efforts in Linear instead. Much, much different but it works well enough while remaining extremely speedy and productive. I do miss a lot of what documents had to offer our team. I don't miss fiddling around with slow documents which didn't offer all of what we needed (and might never offer it). I'm not sure why but most document-based apps like this seem to develop terrible performance. I suspect it's genuinely a difficult problem; I don't think I can 'make Notion in a weekend' by any means, or Slite for that matter. I trust they're doing their best. I also know these tools suit some teams incredibly well, too.

polote 5y ago
Honestly I think this is because Notion, Slite are mostly frontend apps at the core. And thus attract talents who are strong in frontend, and the culture is biased toward front end (actually in Notion it is even biased toward UI). And thus they neglect backend due to their culture which leads to performance issues. I agree that you can't do Notion in a weekend, I have been working on something similar and it took me 8 months full time to have something that starts to look ok. But that's also why I'm not bearish on having good performance in that kind of app. Notion made very dubious choices regarding their data model which explains why it is slow. Slite did not, but I thought that Slite had better performance though
lming 5y ago
You are absolutely right that building a performant rich-text-editor for large document is indeed a very difficult problem. Mixing real-time collaboration put further challenges on api design and server processing. It's a whole different level of engineering challenges compare to building a performant CRUD web app... I am wondering how your team does note taking in Linear - are you guys create one issue for each document? It doesn't support collaborative editing, right?
- steve_adams_86 5y ago
  I should have been clearer. We essentially abandoned note taking and began storing all of our tasks in linear in a more granular way. We also all began participating in our issue management more, as it became sort of like the core of project management for us. Looking at linear can give you a very clear picture of where the team is right now, what we’ve been doing, and even what we will be doing. Our issues are a place where we discuss implementation decisions, relate issues together in various ways to provide more clarity, link to external resources relevant to issues, and we organize them into projects and cycles as well. The goal was to convert a process we already used into a more robust and useful process which might make note taking redundant. It has mostly worked. Since we work in software and we’re a small team that’s intimately familiar with most of our code (or at least what the code does), tooling and practices like version control, idiomatic naming conventions, and supplemental commenting in code can helpfully serve as sufficient documentation for the team right now. It’s a much different thing from real-time collaborative documents though and I do worry that as we grow, it won’t benefit less technical roles we’ll need to support the team. That’s where something like Notion becomes very compelling to me.