5 ms·

When I used to work in manufacturing, my company was super into Lean. I even ended up getting an ASQ Six Sigma Green Belt certification. My favorite thing to sa

When I used to work in manufacturing, my company was super into Lean. I even ended up getting an ASQ Six Sigma Green Belt certification. My favorite thing to say to people when they asked what 5S stood for was "Shove Stupid Shit Someplace Secret". In my experience, that wasn't an entirely inaccurate interpretation. Joking aside, I think this article does a decent job of translating Lean manufacturing principles to coding, but the "Set in Order" section grinds my gears a little bit. I have worked on many projects of various sizes, and I think my fellow web devs tend to lean too hard into an overly nested directory structure. In manufacturing terms, imagine if you needed to open a cabinet that contains a toolbox with a plastic organizer in one of the drawers that contains a box that you had to open to get access to some rivets. It doesn't take much for that level of organization to kneecap efficiency. I would much rather have a single directory with 20 files than try to chase down a component file that's eight directories deep. Give me a big list of long descriptive file names, not short names that rely on the directory name to give context.

datameta 2y ago
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.
- 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?
pphysch 2y ago
> "Shove Stupid Shit Someplace Secret" This sums up the broad concept of Compliance and security in general. The people who pretend to care about compliance (i.e. management) don't have the technical know-how to grok the implementations by those who pretend to implement said compliant systems. There isn't remotely enough QA/red-teaming (expensive to do in a bias-free manner), most of the time all you need to do is scribble in the box and everyone is going to squint and pretend it's checked.
- jimbokun 2y ago
  I work on software for the healthcare industry, and recently found out about PHI (private health information) insurance. Basically they pay out if you suffer a breach, The part I found interesting is that the premiums vary based on their assessment of your practices. This strongly aligns their incentives with actual best practices when evaluating your systems, as they are on the hook financially for any breach.
osigurdson 2y ago
The problem with relying on a tree is most brains don't organize information like that. This is why code search is much more valuable. Naturally, having one canonical tree representation is obviously a good idea but the value is really in introducing a constraint that acts as a forcing function (if done right) to simplify the code base (it can also be theater - spaghetti code masquerading as as well structured code base).
jiggawatts 2y ago
The folder thing is something I’ve noticed too. The problem with folders is that in most interfaces you can’t see their content until they’re opened. In some really bad interfaces you can only see one open folder at a time. Flat lists let you see the entire thing at once. As long as there is some sort of natural sort order, it’s still a “neat” way to organise things. E.g.: SomeApp-PRD-Web SomeApp-PRD-DB OtherApp-PRD-Web OtherApp-PRD-DB OtherApp-PRD-API Is roughly how I organise cloud resources. You can instantly see that there are two apps, and that both are web+db but the second one also has an API. If you had folders you’d just see this: SomeApp OtherApp That just tells you that there are two apps, and nothing else. You have to navigate several times to get to the detail you could see at a glance with the flat structure. Similar concepts apply to code at every level. I avoid overly abstract functions that do their job through seven levels of trivial abstractions for the same reason. A one-page “flat” function can be more readable and maintainable.
bruce511 2y ago
Every time I get involved in a project it seems to start with this neatly organised tree where everything is squirreled away. By contrast my own systems are often just one giant folder. Conceptually I'm just not bothered by large directories with 20000 files. And I'm happy to mix files of different types in one folder (OMG .c files and .ico files in the same folder like a barbarian!!!) I find the system is simple, and everything I need is in one place. But it freaks people out. I guess we're all just wired differently. (Obviously there is organisation, I have different projects in different folders etc, but there's no "extra" organisation. I don't make more folders just because this one is "full".)
- vmurthy 2y ago
  It maybe that this works for you individually, but does it work well as part of a team? I think it's one of those cases where one needs to do what is convenient for most of the team rather than one member?
  - anonymoushn 2y ago
    Are there people for whom it works better to have nearly as many folders as files?

datameta 2y ago

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

pphysch 2y ago

> "Shove Stupid Shit Someplace Secret" This sums up the broad concept of Compliance and security in general. The people who pretend to care about compliance (i.e. management) don't have the technical know-how to grok the implementations by those who pretend to implement said compliant systems. There isn't remotely enough QA/red-teaming (expensive to do in a bias-free manner), most of the time all you need to do is scribble in the box and everyone is going to squint and pretend it's checked.

jimbokun 2y ago
I work on software for the healthcare industry, and recently found out about PHI (private health information) insurance. Basically they pay out if you suffer a breach, The part I found interesting is that the premiums vary based on their assessment of your practices. This strongly aligns their incentives with actual best practices when evaluating your systems, as they are on the hook financially for any breach.

osigurdson 2y ago

The problem with relying on a tree is most brains don't organize information like that. This is why code search is much more valuable. Naturally, having one canonical tree representation is obviously a good idea but the value is really in introducing a constraint that acts as a forcing function (if done right) to simplify the code base (it can also be theater - spaghetti code masquerading as as well structured code base).

jiggawatts 2y ago

The folder thing is something I’ve noticed too. The problem with folders is that in most interfaces you can’t see their content until they’re opened. In some really bad interfaces you can only see one open folder at a time. Flat lists let you see the entire thing at once. As long as there is some sort of natural sort order, it’s still a “neat” way to organise things. E.g.: SomeApp-PRD-Web SomeApp-PRD-DB OtherApp-PRD-Web OtherApp-PRD-DB OtherApp-PRD-API Is roughly how I organise cloud resources. You can instantly see that there are two apps, and that both are web+db but the second one also has an API. If you had folders you’d just see this: SomeApp OtherApp That just tells you that there are two apps, and nothing else. You have to navigate several times to get to the detail you could see at a glance with the flat structure. Similar concepts apply to code at every level. I avoid overly abstract functions that do their job through seven levels of trivial abstractions for the same reason. A one-page “flat” function can be more readable and maintainable.

bruce511 2y ago

Every time I get involved in a project it seems to start with this neatly organised tree where everything is squirreled away. By contrast my own systems are often just one giant folder. Conceptually I'm just not bothered by large directories with 20000 files. And I'm happy to mix files of different types in one folder (OMG .c files and .ico files in the same folder like a barbarian!!!) I find the system is simple, and everything I need is in one place. But it freaks people out. I guess we're all just wired differently. (Obviously there is organisation, I have different projects in different folders etc, but there's no "extra" organisation. I don't make more folders just because this one is "full".)

vmurthy 2y ago
It maybe that this works for you individually, but does it work well as part of a team? I think it's one of those cases where one needs to do what is convenient for most of the team rather than one member?
- anonymoushn 2y ago
  Are there people for whom it works better to have nearly as many folders as files?