Agree with your sentiment. Contextuality and Applicability are definitely two main components when it comes to knowledge acquisition. But there are people who just derive pleasure from learning, irrespective of whether the concepts are connected or disjoint, and I think it is very important that we have all variety of people, and encourage them into pursuing what gives them satisfaction.

> There is a reason you forget things you read about - you don't really need them and your brain does you a favour by forgetting.

Maybe this is my neuro-diversity showing, but my personal experience WILDLY disagrees with that statement.

Do you often forget important things? Very few people do that, they forget stuff that are easy to look up but rarely forget stuff that matters. Like, would you forget about your minimalist philosophy or whatever you live your life after? Probably not, if you do you have a mental problem.

Your problem is more likely that you value trivia knowledge rather than forgetting important things. Trivia is not important.

What I tend to find is that importance itself is a shifting concept. I've been at the same company for a few years and worked on many projects in different areas. When I start a new project, I tend to forget a lot of the details of the previous one. Then I later get pulled in for information or for a new project that builds on the previous and that old forgotten information becomes valuable again.

Then there's the fact that the keeping of the wiki itself is something I use for rubber ducking and the Feynmann technique.

"Maybe this is my neuro-diversity showing" Who talks like that? What a weird flex.

It's common in the autistic community.

> The premise here is to accumulate knowledge for the sake of knowledge itself. In my experience this isn't productive, takes time, and is not going anywhere.

And since when can't people do things because they like it? Why does everything need to be productive? That sounds depressing to me.

I just assumed that it is productivity oriented, based on the contents, and also based on other such systems that come with stated goals of "organising", "learning", "remembering". I think they are in the majority. Doing something like that for satisfaction would have different emphasis, in my opinion. Like storing articles about rocks, animals, martial arts, crafts of beer, and things of that nature.

Can't speak for everyone but my contents are the similar and I also want to organise/remember/learn it in order to progress. I just want to understand the world as best I can and that requires learning and structuring knowledge. I have no intention of applying it for anything other than coincidentally.

I would call it "knowledge hoarding". Reminds me of people who have 50,000 photos on their phone - only to never look at them again. It would make sense if life was a bit longer.

Reminds me of “learn like you’ll live forever, live like you’ll die tomorrow”

> For me - a better alternative is to only seek and store knowledge about things you are currently working on, and organise it by project.

That's the PARA method in a nutshell

https://fortelabs.co/blog/para/

I use this, very helpful, the prioritization piece is by far the most important, if you don't need it now but think you might later, just throw a note with a link in the archive with a couple of tags.

You can do both. For example, let's say you start organizing by project. Pretty soon, there's overlap between projects and you end up re-documenting. So you can abstract the information into a more general framework and reference it within the project files.

This has additional benefits for efficiency, (DRY) and also usually gives you a result which is generally easier to share with the public, if for example your project file is too personal or too deep for easy reading all by itself.

> For example, let's say you start organizing by project. Pretty soon, there's overlap between projects and you end up re-documenting.

But there is no reason to re-document. It takes time and doesn't give anything for the project. I typically just have a "meta" folder within a project and any related pdf/video/html I stumble upon goes into that folder. I wouldn't care if a few projects share the same file.

In this case DRY also, in my opinion, only gets in the way. Say you abstract the knowledge to a separate system and start referencing it from your projects. What this does is it freezes the knowledge organization within your system. You cannot relabel things or move them around, because the links from projects to your knowledge base will get broken. This would only add unnecessary complexity and inter-dependance. DRY is one of those things I started looking at differently some time ago. Repeating yourself, in certain cases, can be faster, simpler and more maintainable.

I think you misunderstood my re-documenting comment. You are referring to assets. I'm referring to things like lessons learned and new systems developed. Proprietary organization is one of the simplest forms this takes. Reinventing even that is a waste of time.

I can also tell some of this is getting into specific case territory. :-) For example, sure, I might not bother referencing a simple component. But that's more like "just Google it" territory. No depth. I have lots of master frameworks that are very deep that I'd never want to repeat. DRY is a life saver there. Those files are also more likely to stay put...

For your moving links scenario, I use search alongside my organization hierarchy and the links double as search prompts. So that's not a problem. I think this is another case where the specifics matter.

I agree with you. At what point does it make sense to just use Google?