Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Right now I'm trying to decide exactly how much information I should store in my knowledge base. There's a balance to keeping the base small enough to actually find the information needed and avoid it becoming a huge bloated mess.

For example, I keep separate Notion pages for each programming language I use. I also recently started learning Rust and have built up a page that includes even basics like how to declare a variable. The idea was it can exist as a beginner guide and someone can run through it relatively quickly and get a jist for the language.

But if I keep using the language, that information may eventually become obsolete (since I'll have it memorized) and will probably be a waste of space. Then as I advance through the language, I'll want to take note of more advanced concepts and maybe even some specific use cases of problems/solutions to code I'll have written.

I guess that's the beauty of editing a knowledge base over time. You can edit it to conform what's in currently in your head right now. So maybe in a few years from now, having those simple variable declarations will be a waste of space and I'll just want advanced topics covered.

Or maybe I'll walk away for a few years and need to look up basic syntax again.



In my experience there's not much risk of having a "huge bloated mess" so write more rather than less.

I keep all my work-related knowledge in just a single flat text file, which after four years at my current company is just under 20,000 lines long and ~750 KB. It's easy to grep and so I can find virtually anything quickly.

I think trying to get too fancy with organization could lead to troubles. A badly-organized knowledge base is hard to fix.

Most of the time I'm just kicking myself that I didn't write down something that I was sure was in there.




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

Search: