December 7, 2025
Copy-paste vs Clever Tricks
Duplication Isn't Always an Anti-Pattern
Copy-Paste Isn’t a Sin? Devs Applaud, Paywall Gets Booed
TLDR: The author argues copying code or structures can be safer than complicated shared designs that create headaches. Commenters cheer the “prefer duplication” mantra, share war stories and jokes, and even roast the paywall—turning a strict rule into a practical, real-world “it depends” lesson.
Software devs are breaking up with the “never duplicate” rule, and the comments are throwing confetti. Yifeng Liu says copying code or making an extra message channel can be safer than forcing a clever, one-size-fits-all design—because bad “abstractions” (fancy shared code) can trap you. The crowd immediately summoned the classic Sandi Metz post, chanting her line like a stadium anthem: prefer duplication over the wrong abstraction. One commenter even flexed: Metz trained their whole team and it “changed everything.” Another voice chimed in: duplication is a small price to pay for isolation—keeping parts separate so one change doesn’t break everything else.
Then came the drama. A paywall mood-killer—“Medium members only”—had folks groaning, turning the access wall into a meme. The funniest jab? A dad-test: if “duplication is always bad,” why are there three copies of the same memo in one office? The vibe became: stop worshiping the slogan and start thinking. Newer devs cling to “Don’t repeat yourself,” but veterans say real projects are messier. Sometimes copying a simple data model or spinning up a second channel reduces headaches, lowers mental load, and avoids the kind of clever trap you’ll regret later. Rebellious, practical, and slightly smug—the comments crowned duplication the unexpected hero.
Key Points
- •Duplication is not inherently an anti-pattern in software development.
- •Bad abstractions or tight coupling can be more detrimental than duplication by increasing cognitive load.
- •A guiding principle is to avoid duplicating the “same thing,” though determining sameness is context-dependent.
- •Real-world projects often require nuanced judgment rather than absolute rules about duplication.
- •Data model classes for service-to-service communication should be simple and avoid business logic, focusing on getters and setters.