i dont consider "not using a database" as a "best practice". a best practice is more like: use the best tool for the task at hand. What you describe would be in-line with this example.
Fair point. But what if there suddenly needs to be a huge expansion in the catalog? What if I need to change or modify several attributes suddenly? How can this thing scale? Ack!
I mean, I completely agree that you should always use the best tool to get the job done and should skip a lot of best practices if the payoff isn’t there. It’s good advice that trumps “best practices” but it’s not really what people mean when they refer to “best practices” and I think you know that.
The problem really is just that people don’t understand that “best practices” are not unconditional rules, but simplified advice representing the common experiences of thousands of people doing the same thing as you. Also, more experienced people like you and me know when it’s safe to break them but that’s a lot less obvious to less experienced people.
Seems like you're agreeing with the person you're replying to. They said the article advocates for avoiding best practices for small projects, and then they provided an example of when they did that - they avoided a "best practice" because it wasn't really practical or important for the task.
penjelly is getting at the idea that a "best practice" can't exist independent of real-world goals
In my example, the perspective is along the lines of: I have data that I need to read and write, so the best thing to do would be to decide on which database to employ in order to do that. It automatically concludes that a database is the best way to store data despite there being other options for handling information
penjelly's perspective is more practical: given the amount and type of data, along with how seldom it's read and written, merely employing any database might be the wrong choice to make since it would introduce extra overhead while complicating the implementation. Therefore, it couldn't be considered a best practice
To be frank, I find the concept of "best practice" a little dogmatic, and a little useless, at least the way I've seen that term thrown around.
In reality, every project is different in its goals and constraints and requires different trade-offs.
Is containerization a best practice? Well it depends on the complexity of deployment. What about unit tests? Code reviews? CI/CD? All of them depend on the project and its real world goals as you said. Which begs the question of whether "a best practice" even means anything.
Anyways, I agree with both you and penjelly. I was just commenting on the fact that penjelly does in fact seem to agree with you as tommychillfiger said.
I think that's where the real discussion is. A lot of things spoken of as a best practice are really just cargo culting rituals when they're not practically evaluated
There was a talk by Julia Evans recently shared here on HN[0]. A great talk overall, but I particularly liked this bit about "best practices" which I think describes the issue beautifully.
> One way I see people kind of trying to share terrible things that their computers have done to them is by sharing "best practices".
But I really love to hear the stories behind the best practices!
If someone has a strong opinion like "nobody should ever use bash", I want to hear about the story! What did bash do to you? I need to know.
The reason I prefer stories to best practices is if I know the story about how the bash hurt you, I can take that information and decide for myself how I want to proceed.
Maybe I feel like -- the computer did that to you? That's okay, I can deal with that problem, I don't mind.
Or I might instead feel like "oh no, I'm going to do the best practice you recommended, because I do not want that thing to happen to me".
TLDR (by me): Don't share best practices, share your experience and let others draw their own conclusions from that.
