3 ms·

> 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 t

> 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.

themodelplumber 6y ago
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.

themodelplumber 6y ago

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.