Bad abstractions have a heavy cost on readability and just your whole teams ability to reason about the program. If your “DRY” change PR removes 1 repeated pie

Bad abstractions have a heavy cost on readability and just your whole teams ability to reason about the program. If your “DRY” change PR removes 1 repeated piece of code but adds in 1 kind of nonsensical abstraction, 1 extra coupling between two pretty unrelated things that use that abstraction, 1 change to the input and output of the function, 1 test suite testing for two separate “things”, etc. it’s not sounding like such a clear positive contribution to the codebase. If we want to go by some of the old adages then a non-dogmatic reading of Single Responsibility - the abstraction should be about one thing - is pretty good in my book.