4 ms·

I actually think it's vitally important to have "dumping ground" locations for things that aren't fully figured-out yet. If I'm working on a new thing and I hav

by _bxg1 6y ago

I actually think it's vitally important to have "dumping ground" locations for things that aren't fully figured-out yet. If I'm working on a new thing and I have something that's relevant in multiple files but I'm not sure where it should go, or even whether it will stick around, I don't want to have to come to a screeching halt just to make a taxonomic decision about something that's still a work in progress. The key, of course, is going back and categorizing those things later once you do have an idea of where they should go.

ryanianian 6y ago
> The key, of course, is going back and categorizing those things later once you do have an idea of where they should go. Yes, but in my experience this is rarely done. It's put off until it gets so convoluted that it introduces bugs. The same is true even if you do avoid dumping-grounds: you need to examine the project's state somewhat regularly to ensure it still makes sense. Where code lives can be as important as the code itself and thus deserves at least occasional review and change.
allenu 6y ago
Totally agree. So much of programming and designing is figuring out what pattern your code is falling into and what stuff "is" or "means". I believe it's totally okay to name things utilities when you haven't yet established a common pattern or understanding of it. Naming things is hard and spending so much time on it and organizing things can often block you from progressing to a place where you DO have more information and can intelligently name things. You'll always be juggling unknowns, so it's okay to have dumping grounds here and there, so long as over time you clean them up as you gain more info.
- _bxg1 6y ago
  I recently started working within a Python codebase, and one of the things I really like about it (not sure whether this is standard Python practice) is that most directories have a "common.py" file in them. So if you just want to put something somewhere real quick, you can elevate it to exactly the appropriate directory-level instead of going to a single, global "utils" file. It's a neat pattern.
- yepthatsreality 6y ago
  Or even using helper/util files as a place for methods that shouldn't be shared or reused. If I write a retry helper to get over an async waiting period then I put that retry method in the helper because it's so utilitarian and contextual I don't want to encourage reuse of said method. If eventually it can be replaced that's good but a dumping ground is a must.
jspash 6y ago
Agreed. I've been using the idea of a "shame file" in css as a dumping ground for this sort of thing. It was brought to my attention by this post https://csswizardry.com/2013/04/shame-css/ https://csswizardry.com/2013/04/shame-css/ And yes, there needs to be a structured and scheduled review and cleanup otherwise it becomes a nightmare. We do this every 3 months along with scouring the codebase for TODO's and FIXME's. It's done in mob-programming style with drinks which makes for a lot of fun and a good way to share our "mistakes". But to be honest, it's starting to devolve into a "coding roast" of sorts!
- limograf 6y ago
  Years ago on a large project with many trainee and junior contributors, I had a sandbox.css as the last css file. Juniors could try out new things and add in naive fixes for bugs. Then in code review we brought the change up into the cascade as a method of teaching cascade thinking. It's rare to do that now as most front end devs are not interested in the cascade and use things like BEM instead. I can understand why - it's pragmatic - but I did personally find that a great way of building up devs who really grasped css on its own terms.

by _bxg1 6y ago

ryanianian 6y ago

> The key, of course, is going back and categorizing those things later once you do have an idea of where they should go. Yes, but in my experience this is rarely done. It's put off until it gets so convoluted that it introduces bugs. The same is true even if you do avoid dumping-grounds: you need to examine the project's state somewhat regularly to ensure it still makes sense. Where code lives can be as important as the code itself and thus deserves at least occasional review and change.

allenu 6y ago

Totally agree. So much of programming and designing is figuring out what pattern your code is falling into and what stuff "is" or "means". I believe it's totally okay to name things utilities when you haven't yet established a common pattern or understanding of it. Naming things is hard and spending so much time on it and organizing things can often block you from progressing to a place where you DO have more information and can intelligently name things. You'll always be juggling unknowns, so it's okay to have dumping grounds here and there, so long as over time you clean them up as you gain more info.

_bxg1 6y ago
I recently started working within a Python codebase, and one of the things I really like about it (not sure whether this is standard Python practice) is that most directories have a "common.py" file in them. So if you just want to put something somewhere real quick, you can elevate it to exactly the appropriate directory-level instead of going to a single, global "utils" file. It's a neat pattern.
yepthatsreality 6y ago
Or even using helper/util files as a place for methods that shouldn't be shared or reused. If I write a retry helper to get over an async waiting period then I put that retry method in the helper because it's so utilitarian and contextual I don't want to encourage reuse of said method. If eventually it can be replaced that's good but a dumping ground is a must.

jspash 6y ago

Agreed. I've been using the idea of a "shame file" in css as a dumping ground for this sort of thing. It was brought to my attention by this post https://csswizardry.com/2013/04/shame-css/ https://csswizardry.com/2013/04/shame-css/ And yes, there needs to be a structured and scheduled review and cleanup otherwise it becomes a nightmare. We do this every 3 months along with scouring the codebase for TODO's and FIXME's. It's done in mob-programming style with drinks which makes for a lot of fun and a good way to share our "mistakes". But to be honest, it's starting to devolve into a "coding roast" of sorts!

limograf 6y ago
Years ago on a large project with many trainee and junior contributors, I had a sandbox.css as the last css file. Juniors could try out new things and add in naive fixes for bugs. Then in code review we brought the change up into the cascade as a method of teaching cascade thinking. It's rare to do that now as most front end devs are not interested in the cascade and use things like BEM instead. I can understand why - it's pragmatic - but I did personally find that a great way of building up devs who really grasped css on its own terms.