3 ms·

As someone who does a lot a "roll your own" programming as a scientist, I never got the appeal of overly nested directories in web dev and other fields, it feel

As someone who does a lot a "roll your own" programming as a scientist, I never got the appeal of overly nested directories in web dev and other fields, it feels a lot like it make things more complicated at least for small projects like the very example they show here. Might as well just have a single directory for three files. Reminds me a lot like OOP examples in tutorials that make a class that only has two methods, too much boilerplate. Like OOP it becomes useful for large systems (GUI libraries) but it's overkill when you have less than ten files I think. EDIT: too late to edit but what I mean in the end of the last sentence is directory structure, not OOP, that less than ten files can be in a single dir without confusing people (or me at least).

breck 6y ago
A directory per project is a good rule of thumb. I generally avoid directories for file "Types", thats what file extensions are for. Also: - Adding a directory to an otherwise flat project at least 2x the complexity, so wait until there's a good reason - Every directory should have a readme. If it doesn't have a readme doesn't deserve a directory.
yourapostasy 6y ago
> ...I never got the appeal of overly nested directories in web dev and other fields... This is often a side effect of many competing interests trying to cram their incentives into a single ontology and then taxonomy. No strong consensus (or a lack of highly opinionated direction) to shape a single concise ontology and taxonomic implementation, so Design By Committee creeps into the decision-making, and creates enough branching to satisfy the "gotta catch them all"-itis to capture all the requirements. That in turn is usually a side effect of the business not knowing its domain sufficiently well to articulate to a granular-enough detail the implementation priorities, and improperly punting that decision to the development organization. "We need this requirement for sure that will as a result prioritize the domain under this ontology. No, wait, we need that. No, wait, we need both even though they are overlapping but mostly disjoint ontologies, and in some places contradictory...." Which finally, is usually in turn a side effect of people leaders managing by KPI's instead of leading teams, to produce results that happen to affect KPI's as a happy side effect. Which is probably where the "leadership that comes up through the ranks is best leadership" comes from, because we often do not find leaders who embody that "lead the teams not the KPI's" characteristic without the deeply-internalized knowledge of the domain acquired by such arduous, time-consuming work over years and often decades within the domain. It's a tough abstraction stack to deal with for everyone involved. There are good solutions, just not quick and cheap ones of course.

breck 6y ago

A directory per project is a good rule of thumb. I generally avoid directories for file "Types", thats what file extensions are for. Also: - Adding a directory to an otherwise flat project at least 2x the complexity, so wait until there's a good reason - Every directory should have a readme. If it doesn't have a readme doesn't deserve a directory.

yourapostasy 6y ago

> ...I never got the appeal of overly nested directories in web dev and other fields... This is often a side effect of many competing interests trying to cram their incentives into a single ontology and then taxonomy. No strong consensus (or a lack of highly opinionated direction) to shape a single concise ontology and taxonomic implementation, so Design By Committee creeps into the decision-making, and creates enough branching to satisfy the "gotta catch them all"-itis to capture all the requirements. That in turn is usually a side effect of the business not knowing its domain sufficiently well to articulate to a granular-enough detail the implementation priorities, and improperly punting that decision to the development organization. "We need this requirement for sure that will as a result prioritize the domain under this ontology. No, wait, we need that. No, wait, we need both even though they are overlapping but mostly disjoint ontologies, and in some places contradictory...." Which finally, is usually in turn a side effect of people leaders managing by KPI's instead of leading teams, to produce results that happen to affect KPI's as a happy side effect. Which is probably where the "leadership that comes up through the ranks is best leadership" comes from, because we often do not find leaders who embody that "lead the teams not the KPI's" characteristic without the deeply-internalized knowledge of the domain acquired by such arduous, time-consuming work over years and often decades within the domain. It's a tough abstraction stack to deal with for everyone involved. There are good solutions, just not quick and cheap ones of course.