>You can legitimately have two functions that are exactly the same but they should not be DRY'd up if they are actually serving different purposes.
I use what I've come to call the "Rule of Three" here.
The first time, don't even consider any kind of abstraction. Just do the thing.
The second time, don't abstract yet. Repeat yourself, but do it in a way that will scale and make abstraction possible, while mentally noting how you might abstract it.
The third time, abstract it.
Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.
I do something similar, but not as precisely specified as this. But I like it.
It's similar to my own rule about when to add a tool. I wait until I'm doing something else and I feel the lack of that specific tool. The first time, it's on my radar. The second time, it's time to get the tool. If you get it on first impulse, you'll drown in tools (and won't give the tools you have a fair shake). If you wait too long, you'll acclimate to not using the proper tool.
I use the rule of "Annoyance". When I get annoyed by having to rewrite what already exists, I'll try to make it DRY, or when I have to fix things in multiple places many times.
I outsource a lot of decisions to that feeling, so I can focus on other things.
It's a matter of time anyway when it's really easy to ask ChatGPT to refactor everything into this perfect code.
I use what I've come to call the "Rule of Three" here.
The first time, don't even consider any kind of abstraction. Just do the thing.
The second time, don't abstract yet. Repeat yourself, but do it in a way that will scale and make abstraction possible, while mentally noting how you might abstract it.
The third time, abstract it.
Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.