Sometimes, it's OK to write the same thing twice if the alternative is a major refactor - such as inventing your own stack.
This seems pretty prevalent among senior developers too, in my experience.
The most egregious case was, this guy I worked with, who would just straight up start with abstractions to avoid any duplication and enable other use cases. Now, 9 out 10 times the use cases catered for by the abstraction failed to materialise (bloody customers) but boy did he let you know when he hit the abstraction lottery and what he'd done neatly fitted in with a new use case.
I think the term for what he created was ravioli code although maybe some of it was lasagne code
Thanks, I'll use that from now on. A lot of wisdom in those 4 words.
1. There is actually a need to use this code in multiple places
2. You know where the places that need this code actually are, and what they need, so what you write will actually be practical for all of them to use
3. Or maybe you can tell that, despite the seeming similarity, the different places are too far apart or too different for sharing code to actually make sense