Hacker News Reader

The rule of three[1] also comes to mind and is a hard learned lesson.

My brain has a tendency to desire refactoring when I see two similar functions, I want to refactor--it's almost always a bad idea. More often than not, I later find out that the premature refactoring would've forced me to split the functions again.

1: https://en.m.wikipedia.org/wiki/Rule_of_three_(computer_prog...

Nice, I advocate for this but never new it was a more formal thing.

better understand DRY first, before you add lots of technical debt to your code: https://news.ycombinator.com/item?id=40525064#40525690

Or alternatively, Write Everything Today.

DRY when it's a wielded as a premature optimization (like all other premature optimization) prevents working code that is tailored to solving a problem from shipping quickly.

Yes, why?

Because you’re unlikely to write a good abstraction until you need it more than twice.

And if you only need the code twice, you very likely wasted time writing the abstraction because copying updates between the two locations is not hard.

This is a rule of thumb, I’m not trying to tell anyone how to do their job.