Oh, now I understand where the directory structure comes from at work. I hate it. The problems I have with it (some of them implementation details that can pr

Oh, now I understand where the directory structure comes from at work. I hate it. The problems I have with it (some of them implementation details that can probably be fixed) - On smaller projects, you have a big directory tree of nothing, with maybe a quarter of the directories being populated. This is because it starts from a template. - You tend to get long directory paths, enough to get over MAX_PATH in some instances, don't fit in a single line, etc... - Remembering arbitrary numbers is hard. Try using arbitrary numbers in your code for your variables, I am sure it will be appreciated... - And especially when there are several number based systems in place. So you have the software version number, the ticket number, the number system used by your customer, etc... Do you really want another number system on top of that? - The article says there is no overlap. There is never "no overlap" in the real life. For example, as a dev, I should have nothing to do in the "sales" folder, except that the technical specifications are here because they are part of the contract. It really belongs in both "sales" and "dev". - I still use search as may primary tool. Note that someone mentioned the military. I have worked on defense contracts, they are the worst. Acronyms and codes everywhere, I guess they are too special to name things with regular words. And I am talking about the unclassified stuff, it is even worse when confidential information is involved: "The name should follow the ZB4455 convention, ZB4455 is in document L45.34c, can I have L45.34c? No it is classified, but actually, it just means it should be lowercase and start with an underscore." So I wouldn't take what the military does as a good example.