5 ms·

Personally I found when onboarding to a repo, whether memory firmware or hardware bringup toolkit, that flatter directories lead to a much slower grasp of the a

Personally I found when onboarding to a repo, whether memory firmware or hardware bringup toolkit, that flatter directories lead to a much slower grasp of the architecture. I prefer leaning toward descriptive directories.

codelikeawolf 2y ago
Different strokes for different folks. I think it's important to find a good balance. I've seen Go and C projects that don't use enough directories, so navigating the code can be a little untenable. In the example given in the article, I would scrap all the subdirectories in `/features/UserManagement`. I think the file names are sufficient to indicate what purpose they serve and putting them in subdirectories by type doesn't really offer any value.
buttercraft 2y ago
The problem is when you guess ahead of time what directory structure you need and get it slightly but not obviously wrong. Start flat, and when that becomes a problem, you'll know why it's a problem and how to restructure it.
- BurningFrog 2y ago
  In general, problems are much easier to solve when you have them, than when you try to guess what they will be.
  - wadadadad 2y ago
    I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight. Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem and create a valid solution and then apply the solution, then if I am able to spot the reoccurring problem after only a few instances. This is particularly worse when I go back and solve the problem in a few areas, but there are more areas that I've missed (and now I have some spots with the solution, some without, and everything is messy). I suppose I need to spend more time after creating a solution to see if it's applicable apply anywhere else (but then that's more time refactoring than actually working on the problem at hand).
    - datameta 2y ago
      Is one effective method perhaps to carve out a consistent, say, 5% of the day to focus on this cross-polination of implemented solutions?
      - wadadadad 2y ago
        This could work (perhaps on a more weekly level for me). I would have to note the solutions and problems as I come across them and put them into a backlog, otherwise I'll definitely forget about them (until I run into them again, haha). This does go back to topic focus though. Regarding programming specifically, I generally will have a topic (such as a feature enhancement). If I implement a new solution to a problem, it's not clear-cut to me if I should go and implement that solution everywhere relevant during the current topic, or if I should wait until a more tech-debt rework to clean things up a bit. My inclination is to focus on rework only during those tech-debt reducing stints. I really should figure out a clear and well-defined process for this.
    - BurningFrog 2y ago
      Those are genuinely hard problems you describe, so don't feel bad about struggling with them. Personally I am very focused on refactoring. When in doubt, if I can improve the code, I will! I don't know that that's "right", but it's how I live.
  - datameta 2y ago
    Very aptly put.
  - casper14 2y ago
    Brilliant
  - buttercraft 2y ago
    This is a good generalization but I worry that it's too broad. I.e. if your lifeboat is sinking, it's too late to find a better lifeboat.
    - hgyjnbdet 2y ago
      But at that point your problem isn't needing a better lifeboat, the problem is why it's sinking. At this point solving the problem of why it's sinking is the problem you've got, solving it before you had that problem seems silly.
mnahkies 2y ago
I like the angular style guides take on this: > Flat > Style 04-04 > Do keep a flat folder structure as long as possible. > > Consider creating sub-folders when a folder reaches seven or more files. It goes more into the why on the actual guide https://angular.io/guide/styleguide https://angular.io/guide/styleguide
candiddevmike 2y ago
Do you like programming in Java?

codelikeawolf 2y ago

Different strokes for different folks. I think it's important to find a good balance. I've seen Go and C projects that don't use enough directories, so navigating the code can be a little untenable. In the example given in the article, I would scrap all the subdirectories in `/features/UserManagement`. I think the file names are sufficient to indicate what purpose they serve and putting them in subdirectories by type doesn't really offer any value.

buttercraft 2y ago

The problem is when you guess ahead of time what directory structure you need and get it slightly but not obviously wrong. Start flat, and when that becomes a problem, you'll know why it's a problem and how to restructure it.

BurningFrog 2y ago
In general, problems are much easier to solve when you have them, than when you try to guess what they will be.
- wadadadad 2y ago
  I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight. Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem and create a valid solution and then apply the solution, then if I am able to spot the reoccurring problem after only a few instances. This is particularly worse when I go back and solve the problem in a few areas, but there are more areas that I've missed (and now I have some spots with the solution, some without, and everything is messy). I suppose I need to spend more time after creating a solution to see if it's applicable apply anywhere else (but then that's more time refactoring than actually working on the problem at hand).
  - datameta 2y ago
    Is one effective method perhaps to carve out a consistent, say, 5% of the day to focus on this cross-polination of implemented solutions?
    - wadadadad 2y ago
      This could work (perhaps on a more weekly level for me). I would have to note the solutions and problems as I come across them and put them into a backlog, otherwise I'll definitely forget about them (until I run into them again, haha). This does go back to topic focus though. Regarding programming specifically, I generally will have a topic (such as a feature enhancement). If I implement a new solution to a problem, it's not clear-cut to me if I should go and implement that solution everywhere relevant during the current topic, or if I should wait until a more tech-debt rework to clean things up a bit. My inclination is to focus on rework only during those tech-debt reducing stints. I really should figure out a clear and well-defined process for this.
  - BurningFrog 2y ago
    Those are genuinely hard problems you describe, so don't feel bad about struggling with them. Personally I am very focused on refactoring. When in doubt, if I can improve the code, I will! I don't know that that's "right", but it's how I live.
- datameta 2y ago
  Very aptly put.
- casper14 2y ago
  Brilliant
- buttercraft 2y ago
  This is a good generalization but I worry that it's too broad. I.e. if your lifeboat is sinking, it's too late to find a better lifeboat.
  - hgyjnbdet 2y ago
    But at that point your problem isn't needing a better lifeboat, the problem is why it's sinking. At this point solving the problem of why it's sinking is the problem you've got, solving it before you had that problem seems silly.

mnahkies 2y ago

I like the angular style guides take on this: > Flat > Style 04-04 > Do keep a flat folder structure as long as possible. > > Consider creating sub-folders when a folder reaches seven or more files. It goes more into the why on the actual guide https://angular.io/guide/styleguide https://angular.io/guide/styleguide

candiddevmike 2y ago

Do you like programming in Java?