I agree with you! I may not have made it super clear, but I think DRY when applied correctly isn't bad. The examples are definitely a exaggeration, but I think the exemplify the style of DRY programming that can happen when you don't agree on how to abstract or define when exactly you shouldn't repeat yourself.
I think having a rule like "Write Everything Twice" is actually the right way of achieving the same end as DRY. You get good abstractions and you don't spend a ton of time trying to generalize the components you don't need to generalize.
I would argue that it is better to have to miss a single instance and have to update it later than to have too many abstractions that have to be really general or abstract to function.
To me, the best abstractions are ones where you don't feel like you are working with an abstraction. Instead it just feels like the "right" way of accomplishing what you are trying to accomplish.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you! I may not have made it super clear, but I think DRY when applied correctly isn't bad. The examples are definitely a exaggeration, but I think the exemplify the style of DRY programming that can happen when you don't agree on how to abstract or define when exactly you shouldn't repeat yourself.
I think having a rule like "Write Everything Twice" is actually the right way of achieving the same end as DRY. You get good abstractions and you don't spend a ton of time trying to generalize the components you don't need to generalize.
I would argue that it is better to have to miss a single instance and have to update it later than to have too many abstractions that have to be really general or abstract to function.
To me, the best abstractions are ones where you don't feel like you are working with an abstraction. Instead it just feels like the "right" way of accomplishing what you are trying to accomplish.