trial and stderrSomething or other has lead me to reading a lot about bad abstractions lately, including a famous article where Sandi Metz writes
duplication is far cheaper than the wrong abstraction
I want to add that it's not just a matter of choosing between two cognizable options. It's that all programmers chronically underestimate the difficulty of inventing new abstractions. We need to take that into account in deciding whether to take the leap in the first place.
I want to reframe the idea of "factoring out common code" and "avoiding copy-pasting." Every time you do one of these simple-sounding things, you are actually inventing an abstraction. You are engaging in the most intellectually demanding act of software engineering. It involves balancing the predicted cognitive load which exists outside, via, and inside your abstraction. It requires you to predict the future about business requirements and code that is yet to be written. On top of all that, it is a test of your mastery of technical jargon, of grammatical norms in programming, and of the English language itself.
Naming has been compared in difficulty to cache invalidation, and yet I don't seem to be surrounded by half-baked attempts at cache implementations.
When Kent C. Dodds says to Avoid Hasty Abstractions, remember that he is a famous expert programmer. "Not hasty" for him sets a pretty high bar for you and me.