One trick I use is to identify whether the duplication involves something that would ultimately be the domain of different modules. If it creates a dependency a

One trick I use is to identify whether the duplication involves something that would ultimately be the domain of different modules. If it creates a dependency across modules, it's a design problem significant enough to probably not result in the abstraction I have in mind right now, so I should let it rest and see how they evolve. And there are definitely cases of duplication too small to matter - which as you note is often the case for UI and UI-like things. You often end up in a position where the most reusable code is, in fact, the copy-pasted code, because the only thing it does is describe a permutation of abstractions and assets glued together. Sometimes this code is not the optimal code, but that's a problem that can be returned to down the line. The easy picks for DRY are one-liner functions that describe a preconfigured intent, like "draw a centered bounding box". That's something your glue code will crave, and there's little issue with deduplicating it later. But even there some tension arises since you can always decouple a little further by having those functions rely on an imperative context where most of the state(e.g. the size or color of the box) was previously configured, versus specifying it at the callsite. After certain thresholds, there's a flipflop between wanting to code it and wanting to configure it.