"Instead of building re-usable software, we should try to build disposable software." https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to
A coworker said (paraph): "90% of the time you create a new thing to abstract 2+ cases, you shouldn't. Use the name as a guide: if your new thing's name makes sense to either 1) a pure CS grad student (is a mathy idea) or 2) a domain expert, then it might make sense. But if it only makes sense to you right now, it's probably not going to make sense to you in a week—or this afternoon."
@22 so true – and I feel like jousting windmills at work. My go to joke is “if the code has more layers than there are members in our team, then that is a problem!” Still, the young ones are smart and love to refactor and extract methods and to find elegant and wondrous solutions to problem – even if a simply copy and paste plus a few changes would be just as well.
If my refactor only makes sense to me, and it's disposable code, WTF cares that I refactor? It's disposable, right? Dispose of it if it doesn't make sense. But, only if it doesn't make sense.
@vertigo That's what @kensanata is talking about, DRY is often at odds with disposable/loose coupling. Another perspective: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
The point my coworker made is, DRY *only if* the result is something obvious from a pure computer science perspective or a pure domain knowledge perspective. If it's not, then RY ("repeat" yourself).
Example: two methods, formatting money and shares by grouping 3-digits & separating with commas—don't DRY this! "NumberGroupFormatter" makes no sense.
@22 Reading that, I think, danged if this isn't also applicable to writing a novel.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!