> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory s

> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory structure. The Antipattern of the directory layout of your typical Java Enterprise Project is a Testament to this. (src/main/java/org/company/product/...) To play devil’s advocate, isn’t the goal of a good IDE to abstract away the actual filesystem organization of the code? As long as I can quickly look up function definitions via the IDE, I don’t care how they’re actually organized on disk. As an analogy, I’m sure my Gmail inbox is internally stored across multiple different databases and would be a nightmare to manually browse at the database level, but I don’t care because I can easily access all my messages through my email client or the web UI. Disclaimer: I’m not an IDE user myself (simply because I’m oldschool, have all the emacs keybindings burned into my muscle memory, and I’ve never taken the time to learn one well), and in principle agree with the author’s point. IDEs are not (yet) at a point where they’ve rendered the filesystem completely irrelevant, although some are getting pretty close.