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