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.
- Forgive yourself. It's okay. You are who you are.
- Understand that there is no speed limit. You can be as fast or as slow as you should be.
- Mimic. Connections and insights are rarely magical. Usually the person has been trained by themselves/others or have come up with mental "hacks" to promote these kind of eureka type thoughts.
Decades ago, my best friend was much better about making connections, insights, etc. I was constantly wowed. Instead of fixed mindset like "I'll never be as good/clever as they are" I simply asked: "How did you come up with that?" or "How did you figure it out?". Sometimes he would point me to how he read documentation and interpreted that into code. Once I got the cryptic answer "Think like an electron." (His point was that similar to how you can predict how water will flow down a mountain, valley, gather against dams, you can kind of predict how electrons move through capacitors, inductors, diodes, etc.)
The point is that I was less interested the outcomes and more interested in how they were achieved.
You'll find that there is a snowball effect. The more connections and insights you make, the easier it is to add to them.
Lastly, the core principles of no zero days might help out. Here's a link to the seminal reddit comment:
The biggest, lowest hanging fruit thing you can do is tell them you are only interested in working at startups and you are only applying to startups. You need this in your resume, linked in profile and also make sure to mention it during the phone screens and onsites.
As an engineering hiring manager for (mostly) startups, I love candidates that have both BigCo and TinyStartup experience. Diversity of thought and usually by then, the candidates have a sense of where they want to work.
If you find that your tech or skills or experience don't line up with startups then you may have some work to do.
Most BigCos need specialists. Most Startups need generalists. Depending on your field, you might need to study up as some other posters have mentioned. I wouldn't study haphazardly however. Apply to a few startups (or industries) you are interested in and take notes of the questions they ask you and especially the questions you struggle to answer. Those are the areas to spend your time getting up to speed on.
The contributor statement is new to me and definitely the highlight of this license:
> Any modification to the software submitted to the authors may be incorporated into the software under the terms of this license.
I'd love something like this become a little more common. Making contributors sign paperwork is a tremendous hassle. Hopefully the OSI (https://opensource.org/licenses) will take a crack at this one soon. If it shows up on their list, I can see adoption ramping up.
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.