I'm happy to answer any questions people have. Initial feedback has been pretty positive so far.
Valid point about how KB Clip is "opt-in". that's intentional as many channels can be like a firehose. The core tenet of KB Clip design is that the most important info should be clipped and it should only take seconds to do so. I love a good pun or gif war and anyone, but not in my wiki or KB.
That being said, I've also got some roadmap features that help surface conversations that heuristically might be important to save as well.
basically it's a slack add-on that allows you to turn a conversation into a web/wiki page in just a few seconds. Essentially, lots of important, KB-worthy info happens naturally during the course of work slack conversations.
The idea being that making knowledge capture easy kind of naturally makes the usage of the knowledge base happen. KB usage is kind of a chicken and egg problem. if no one creates info, no one will look there.
We don't currently export to Confluence, but the plan is to export to most of the major wiki/KB platforms. We're going thru Slack App Directory approval process at the moment, but we're planning on doing a big marketing push as soon as that happens.
happy to answer any question about this topic or the product we're building!
I don't think you can prevent people from migrating to discord or slack, but I built a Slack app that tries to bring the best and most frequent conversations to the web.
The issues brought up here are exactly what I am trying to solve.
- It’s quirky
- There’s a learning curve
- Taking the time to climb that curve can result in elegant solutions
- The endgame is high developer efficiency
Not only that, but I find it fun and enjoyable. The ecosystem isn't the largest, but the other positives more than make up for the deficits for me.
I only started learning elixir around November or so last year and I've launched two SaaS products in the past 6 months.
Anecdotally, having managed elixir teams and talked to other managers of elixir teams:
- The learning curve is real. but 2-6 months for us, not years. It's not particularly hard, just longer than a small language like go.
- Having Ruby and/or functional programming experience shortens that learning curve.
- Developer experience/satisfaction is very high. This helps retention
- Some devs will just never "get/grok" Elixir. They may have 20 years of java experience or a new dev better suited to a FE role. This doesn't mean they are bad, just not a great fit.
- The devs that do get it? They are quite productive. Feature velocity is high.
I disagree that Elixir/Phoenix isn't a fit for CRUD apps. I'm seeing high feature velocity across small and large scale products.
In particular, feature velocity per engineer is quite high. A smaller team in Elixir/Phoenix/LiveView can outpace a similar full stack team.
static typing is what drew me to go, Elixir isn't a static-typed language, but there are plenty of guardrails in the language that make up for it. Pattern-matching, guards, good compiler messages, casting, etc.
You've also got fantastic testing framework, and good conventions like tagged tuples {:ok, x} vs {:error, y}.
On top of all of that, you've got the Erlang underpinnings: immutability, crash-fast, app umbrellas, etc.
It's a very safe language to develop in. I don't miss the strict static typing at all.
I'm happy to answer any questions people have. Initial feedback has been pretty positive so far.
Valid point about how KB Clip is "opt-in". that's intentional as many channels can be like a firehose. The core tenet of KB Clip design is that the most important info should be clipped and it should only take seconds to do so. I love a good pun or gif war and anyone, but not in my wiki or KB.
That being said, I've also got some roadmap features that help surface conversations that heuristically might be important to save as well.