[ramesh31]

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

[javajosh]

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.

[mewpmewp2]

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.

[kitkat_new]

> Adhering to this, the vast majority of code will never reach that third stage, thus taming the complexity beast.

yeah, because you probably forgot about at least one of the other repetitions somewhere in the code

as a developer you should know if it makes sense or not

[evntdrvn]

I call it WET, “Write Everything Twice”. It’s catchy enough that people remember/follow it, esp with the antonym making it memorable :)

[getoffmycase]

Thanks for putting the process of what I did twice in the last two days into clear, coherent words and logic.