Hacker News new | past | comments | ask | show | jobs | submit | page 2 login
Ask HN: How do you share/organize knowledge at work and life?
781 points by gavribirnbaum 54 days ago | hide | past | web | favorite | 296 comments
I find it hard right now to share knowledge with everyone on the team and to turn knowledge into actual learnings.

I don't know how you guys do it, but I would love to know. We are now 50 people in the company and I don't know anymore how to make this scale. What is your process? Do you use any tool for it? How good is it? What needs improving?

Self-promo: I'm currently building software called Thanks For Sharing.

At launch, we'll be focusing on features that help employees to provide feedback to their organization leaders.

We're also exploring requirements for building out internal knowledge bases for organizations that have more sharing and communicative elements. Link in my bio if any are interested.

Would love to get in touch with you as we are developing a tool at this moment, exactly for this purpose. Target is a cross between jira and notion. your experience is valuable, and you would be granted life-free usage.

Edit: Agree with afarrell though a good tool should guide processes and be actively used also in operations for information And knowledge not to be dated.


I try to use Jira whenever I can. It sucks. But the thing is everything else also suck so for me Jira sucks a little bit less.

Apart from being pretty slow, I don't think Jira really sucks once a) it is configured to your needs b) you know how to use it (which should be fairly easy with a in place). Which goes for pretty much any tool more complicated than notepad, so to speak: it's not like the other similar tools out there are much better, just different, imo. Though I have the impression a lot of people who think Jira sucks might be using it where they actually don't need it because much simpler tools could suffice in their particular situation.

All tools suck in a way that actual reality of doing work is complicated and tools are obviously way simpler so you end up trying to reduce the reality to fit the model of a particular tool.

That explains why email is still the most used tool. It also sucks but you can do any type of project with email and everyone knows how to use it.

Our team uses a Q&A system called Scoold for knowledge sharing. It's basically a Stack Overflow clone and has great team support. https://scoold.com

Rwtxt.com for personal stuff. Minimalist, simple, supports markdown, exports data and can be self-hosted with no hassle (it's a go binary, and that can run anywhere, and it uses sqlite, so no complicated db setups). It works for small groups too, though it breaks when two people try to edit aat the same time.

QOwnNotes, cross platform open source app for creating/editing/tagging/searching markdown files, synced with NextCloud. I've finally found the system that doesn't hold me back, and I've stopped looking for anything better.

This is for my own personal use, maybe/probably not as suitable for a team.

I have a directory named “mystuff” that’s gitignored globally, in every repository I work on. This is where I store commands, snippets, scripts, ideas, meeting notes etc. To organize things I find on the web, I simply use bookmark folders in the browser.

In our company we use both github wiki and google drive to share knowledge.

A combination of indexed markdown documents, org-mode with orgzly (android) and devonthink (macos) as a gui Thinking of using TiddlyWiki as gui again as it works with Firefox Reality in the Oculus Go and Quest, but it doesn't work well with markdown and org-mode documents. Perhaps use it as yet another system.

I've tried a lot before. Ended up creating a tiny wrapper around my terminal text editor: https://crates.io/crates/mj

It essentially is markdown files in the fixed directory structure, searchable and simple.

I use http://diigo.com to quickly bookmark/tag/annotate links I find. It is about the most advanced bookmark manager out there with capabilities to store copy of page/pdf with annotations, search content etc.

I've used Bookmark OS for bookmarking for a couple years and have recently started using it for notes as well. It allows for sharing folders of bookmarks and notes with teams https://bookmarkos.com

Recently I found out Balsa (https://github.com/balsa-team/balsa) - which looks promising since it has a WYSIWYG editor with comments, plus can be deployed on premises.

http://fellow.co has been immensely helpful for me , it has every thing I need to manage information at work place and also has a personal section which is useful. I would recommend you to give this a try

Personal : small library of notebooks, I generally dont share these

Professionally : physical notebooks and Onenote books. Every time I join a new team I start a new notebook and when I leave I pass it to someone else if they want it. My Onenote files are publicly accessible to anyone.

Mostly meetings and word of mouth. That's why I lose one week+ on a lab software that I cannot make run on my local development machine. Even personal projects I spend a few months on are better documented than the software that is used here in production.

I like to use https://www.are.na/ to collaborate and collect ideas, knowledge etc.

I use google keep for writing notes. In work we use the enterprise garbage all others use too. Google calender for datespecific stuff. Anything coding specific i have in github as markdown documents, some remain as drafts in my blog repository.

Confluence for team sharing. Also copious comments in the code, documenting WHY something is written as it is.

I recently replaced org-mode with Joplin. My more visual notes are in OneNote, which supports the Apple Pencil for drawing and writing.

vimwiki has been life transformational for me.


Shameless plug: Twinkle Notes is a cross platform solution for building private personal and team knowledge base. Currently in beta.


I write into bunch of markdown files and push to GitHub:


[gollum](https://github.com/gollum) powers GitHub's wikis. I've used it and it seems alright.

I tried notion and coda, which are both AMAZING products and are vastly superior to Google docs.

But I ended up back at Google docs. Everyone has it, simplifies sharing and planning vacations massively.

You can use https://wreeto.com. It's easy to share organised knowledge with a public link.

At Sourceress we formalized skillsharing with a simple spreadsheet. Now, engineers teach each other the skills that we want to spread throughout the org.

Personal: Onenote - for mobile and tablet Work: Confluence wiki

How you organize/classify/process information is more important than the tool imo.

I use Google Calendar to schedule things to be done.

For note-taking, I use https://wreeto.com.

I'm working on a mobile app with flutter that lets me take personal notes and also keep track of my side projects.

Mostly in my brain, some of it in a calendar and even less in my smartphones note app.

At work I've started using Balsa and at home I usually use Sublime+git.

Automation and efficient documentation.

Proper ownership and decoupling teams and services.

Pair programming.

By the way, does anyone has tried Stackorvelflow for teams? Is it good?

We tried. It's pretty much like the normal stack overflow (Question and Answer based).

But we found that in the end - a normal wiki was actually more useful. I think this was mainly because of how our organization works. We're all physically on the same campus, at most a colleague is 2 minutes walking away. Hence we tend to often have in-person communication, or first via Slack, after which a colleague walks over to explain it anyway..

Using a wiki, the person knowledgeable about the domain can just create a document to refer people to which is quite natural. What is not natural for this person is to create a question and then answer it himself. (I know you could use SO as a wiki but than you're losing some of the utility anyway).

I'm not saying that it can't work, but a lot depends on company culture / structure, at least I think so. So if you're in a situation where people often post questions on slack and people respond through slack, maybe SO is a good alternative.

(Oh also, on another note, during our test people would post question on SO and no one would answer because no one is looking, or people think "someone else will answer" and don't bother to check up later. Via slack, at least it's more visible and scoped to the correct channel with the correct people for the domain).

YMMV ofc :)

We use teamemo(teamemo.com), a german based wiki-software at work.

I use my deep, mind-mapping tool: jumproot.com.

Trello everything

does blogging count? I write blogs to share what I learn and I learned a lot from other bloggers.

My team and I use Taskade at Go X.

Apple Notes + Confluence + Slack.

Yellow Post-It notes, mainly.

A wiki comes to mind.

i write notes with a web system build my own.

I'm a stickler for well-written tickets.

In general: All products have a few pieces of information that must be clearly provided in a bug report (or support escalation.) For my product, (desktop file sync,) this includes build version, unedited log files, filenames, and clear steps to reproduce.

Industry-wide, a clear ticket title that is more than "XXX doesn't work," that uses known product terminology, is also important. [Edit] Also critical is that information that defines what the ticket is, such as clarifications, and updating the steps to reproduce, shouldn't be buried in comments. Edit the ticket description.

Poorly-written tickets, either because they are missing agreed-upon information, like log files, or because they just don't explain what the problem is, are sent back. I tell all my engineers to regularly look through their tickets and send anything back that's confusing; so once they are able to work on the ticket, everything they need is there.

Another critical thing: It's important that tester follow good practice for your specific product. I've had testers attach videos, but ignore log files. Videos might be very useful in a product that the tester worked on in an old job, but they very rarely are helpful when trying to diagnose why a file isn't uploading. (That's why we have logs.)

The final critical thing: Managers must respect what engineers need in tickets. This means that the testers' manager should be instructing testers in the specific items of information that they need to collect for your product. If a manger doesn't respect the fact that you need logs (or whatever else you need) present in every bug report, your problem isn't communication. It's that you have a manager who doesn't respect the needs of your business.

[Edit] Why is it important to be a stickler, and make sure that tickets are well written? When you have to look at a LOT of tickets, you don't have the time to read through 100 comments in each ticket, and then spend an hour trying to reproduce the ticket just to understand what the problem is. If you have a lot of tickets that don't make sense within the first 60 seconds that you look at the ticket, then you need to figure out how to improve ticket quality.

Another thing: Don't combine bugs into the same ticket. This happens when testers start doing things like failing verification because they found a new bug. (Does the ticket refer to the new bug or the old bug. How come, when I follow the steps to reproduce, I can't reproduce the bug?) This also happens when testers think that the same bug has multiple steps to reproduce. It's always easier to close a bug as a duplicate, than the fix one bug in a ticket and keep the ticket open for the other bug.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact