How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
I’ve tried completely flat projects before that’s had some mileage before it got too much, then I added some folders but this subject, it’s not actually important because we have amazing find in files features built into everything, don’t get hung up on it ✌️
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
That's actually not true. If you're working on a giant codebase where there's no organization behind folder/directory structuring or assigned naming conventions, it'll prolong your onboarding process a great, great deal.
Being organized with this kind of stuff means being cost-effective and empathetic to your coworkers.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
you have find in files, your folder structure is irrelevant in this context, that is how as somebody who had no-one to onboard me got around and its battle tested, its true in my context certainly not false.
I have also stated that at a small scale, no structure a flat structure is sufficient at a prototyping phase, adding what you need, when you need it. Im sorry if you disagree but from my experience thats what I have seen.
I think its absolutely okay and valid approach if it's a personal project. Then the only pain you'll receive there will be one of your own doing.😆 But when working with others I wouldn't advise others to "not get hung up on structure". I think that kind of mindset is a gateway to start writing legacy code that nobody wants to touch in the future because messy/sticky/non-comprehensive.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
My point is iteration is superior to perfection and organisation that will change countless times in the beginning, why don’t you as an experiment write a todo list in a flat structure with no folders, and then explain where the folders start to be needed, that would be an interesting post no?
Not really following your thread there. Anyway - all I know is that if I had to work with someone who had zero care in the matter, I'd be worried about the impact that developer's code would have as far as maintainability goes. But you do you! I'm honestly not here to argue. I just felt it was important to point out another perspective. Hope you have a nice day!
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
I'm actually in complete disagreement with this statement... its only true if you've worked there for years and know the application history. If not, finding via string search in 100k lines of code is often, more often than not, nightmarish.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
I use for example ECSS a system that is designed to group css by a 3 letter namespace and that is a point that conventions are often found more in files than folders so identifying patterns and searching are indeed skills that a developer must aim to improve on.
I did state as many have missed that there is a limit read the entire comment
Great system... but rings my point home too... ive been in many a code base developed by 1000 engineers, where css policies are different throughout precisely due to iteration by each developer individually, without a common folder structure, without a standard... this is the common folly of iterative design, it's equivalent to shoot first and ask questions later, which is definitely appropriate in some scenarios. Imagine an app where the login page uses your standard, the home page uses nested Ultra specific css and the dashboard uses bootstrap... worst case scenario... now imagine everything in the same folder, or even just organized by file type. Plan for the future, plan for architecture... there is a big difference to me between Programming and Software Engineering.
Really man, this is old 1980s vim approach. Software architecture is very important, you don't have any of it if all files are flat in a 1000 file application. But even in the vim days we considered architecture. Iteration is actually the least effective method of implementing, short and long term. How would you feel if they built bridges via iteration, why would this be okay for heart monitor software, or even a web-based front-end where personal information can be leaked... there is only one reason, lower upfront cost if you ignore architecture, régulation, new hire onboarding time, comprehension time for when devs modify each other's code, etc, etc.
But when you start a business, actual operating costs far exceeds upfront... so plan for the future and flat file word search ain't it... at least use the IDE click to go feature, faster than typing when tracing and also confirms object is accessible in real time.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
I’ve tried completely flat projects before that’s had some mileage before it got too much, then I added some folders but this subject, it’s not actually important because we have amazing find in files features built into everything, don’t get hung up on it ✌️
I dont understand what this mean, can you write in plain english? Thanks
Bristolian to English translation:
That's actually not true. If you're working on a giant codebase where there's no organization behind folder/directory structuring or assigned naming conventions, it'll prolong your onboarding process a great, great deal.
Being organized with this kind of stuff means being cost-effective and empathetic to your coworkers.
you have find in files, your folder structure is irrelevant in this context, that is how as somebody who had no-one to onboard me got around and its battle tested, its true in my context certainly not false.
I have also stated that at a small scale, no structure a flat structure is sufficient at a prototyping phase, adding what you need, when you need it. Im sorry if you disagree but from my experience thats what I have seen.
I think its absolutely okay and valid approach if it's a personal project. Then the only pain you'll receive there will be one of your own doing.😆 But when working with others I wouldn't advise others to "not get hung up on structure". I think that kind of mindset is a gateway to start writing legacy code that nobody wants to touch in the future because messy/sticky/non-comprehensive.
My point is iteration is superior to perfection and organisation that will change countless times in the beginning, why don’t you as an experiment write a todo list in a flat structure with no folders, and then explain where the folders start to be needed, that would be an interesting post no?
Not really following your thread there. Anyway - all I know is that if I had to work with someone who had zero care in the matter, I'd be worried about the impact that developer's code would have as far as maintainability goes. But you do you! I'm honestly not here to argue. I just felt it was important to point out another perspective. Hope you have a nice day!
I promise there is no argument here I’m also presenting the alternative point of view as well 😊 have a lovely day
Absolutely! Which is totally valid as well. Thanks.😊
I really enjoyed this thread, it is insightful. Learnt alot from you guys perspective.
I'm actually in complete disagreement with this statement... its only true if you've worked there for years and know the application history. If not, finding via string search in 100k lines of code is often, more often than not, nightmarish.
I use for example ECSS a system that is designed to group css by a 3 letter namespace and that is a point that conventions are often found more in files than folders so identifying patterns and searching are indeed skills that a developer must aim to improve on.
I did state as many have missed that there is a limit read the entire comment
Great system... but rings my point home too... ive been in many a code base developed by 1000 engineers, where css policies are different throughout precisely due to iteration by each developer individually, without a common folder structure, without a standard... this is the common folly of iterative design, it's equivalent to shoot first and ask questions later, which is definitely appropriate in some scenarios. Imagine an app where the login page uses your standard, the home page uses nested Ultra specific css and the dashboard uses bootstrap... worst case scenario... now imagine everything in the same folder, or even just organized by file type. Plan for the future, plan for architecture... there is a big difference to me between Programming and Software Engineering.
No worries man, take care.
Really man, this is old 1980s vim approach. Software architecture is very important, you don't have any of it if all files are flat in a 1000 file application. But even in the vim days we considered architecture. Iteration is actually the least effective method of implementing, short and long term. How would you feel if they built bridges via iteration, why would this be okay for heart monitor software, or even a web-based front-end where personal information can be leaked... there is only one reason, lower upfront cost if you ignore architecture, régulation, new hire onboarding time, comprehension time for when devs modify each other's code, etc, etc.
But when you start a business, actual operating costs far exceeds upfront... so plan for the future and flat file word search ain't it... at least use the IDE click to go feature, faster than typing when tracing and also confirms object is accessible in real time.
Op:
80s eh, I’m not that old and I don’t use vim 😂
I use well-structured folders so I don’t have to rely on find in files.