DRY is Not Always Clean

Do Not Repeat Yourself or DRY to save time in milliseconds is the golden rule of programming that most of the developers follow. It sounds wise. Efficient. Mature. Like something a programming monk would chant while typing 120 WPM with zero typos. “Every piece of knowledge must have a single, unambiguous, authoritative representation.” Translation: No duplicate logic, no copy-pasted functions, no if-it-works-don’t-touch-it attitude. DRY, a principle coined by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer, is all about minimizing duplication and promoting modular, reusable code. The core idea? Write logic once and reuse it wherever needed. In theory, this leads to a smaller, cleaner, and more maintainable codebase, one that’s easier to debug, scale, and understand. function calculateDiscount(price: number): number { return price * 0.1; } Nice and tidy. One place to rule them all. But there's a catch. What happens when different parts of your code need slightly different logic? That one helpful function quickly becomes a bloated mess of if-else gymnastics. Write Everything Twice WET is like a programmer in a fancy tuxedo at a code review, sipping espresso and saying: “Relax. It’s totally fine to repeat yourself. Just make sure your teammates don’t cry trying to read it.” Write Everything Twice proudly welcomes a little duplication. Instead of abstracting everything like you're solving quantum physics, WET says, “Chill, just copy-paste it if it makes things clearer.” Especially in early development, when features pivot more than your mood on a Monday morning, writing things out twice might just save your sanity. function sendEmailToAdmin() { /* admin-specific logic / } function sendEmailToUser() { / user-specific logic / } Sure, it’s a little repetitive. But it’s also obvious what each function does. No detective work. No 17 nested utility functions. No crying in the break room. Just readable, understandable code. Avoid Hasty Abstractions (or Let It Cook) Coined by Kent C. Dodds, AHA encourages waiting until you see a real, repeated pattern before DRY-ing things up. It’s the wise old wizard of the programming world that instead of jumping on abstracting everything like a DRY disciple on espresso, AHA whispers, “Patience, young coder. The time to abstract will reveal itself.” function createAdminProfile() { / some admin stuff / } function createUserProfile() { / some user stuff / } // After a while, you notice a shared pattern... function createProfile(role) { / shared logic here */ } Think of it like dating your code before marrying it into a shared module. The idea is to let duplication exist temporarily while the codebase evolves. Then, when the patterns are clear and stable, swoop in like a coding ninja and extract that sweet, maintainable logic. When to use what? Scenario DRY WET AHA Obvious, repeated logic across files ✅ ❌ ⚠️ Similar code that may diverge later ❌ ✅ ✅ Early development stages ⚠️ ✅ ✅ Shared business rules ✅ ❌ ⚠️ Final Tip Good developers write DRY code. Great developers know when not to.

Apr 30, 2025 - 18:37

Do Not Repeat Yourself or DRY to save time in milliseconds is the golden rule of programming that most of the developers follow.

It sounds wise. Efficient. Mature. Like something a programming monk would chant while typing 120 WPM with zero typos.

“Every piece of knowledge must have a single, unambiguous, authoritative representation.”

Translation: No duplicate logic, no copy-pasted functions, no if-it-works-don’t-touch-it attitude.

DRY, a principle coined by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer, is all about minimizing duplication and promoting modular, reusable code.

The core idea? Write logic once and reuse it wherever needed. In theory, this leads to a smaller, cleaner, and more maintainable codebase, one that’s easier to debug, scale, and understand.

function calculateDiscount(price: number): number {
  return price * 0.1;
}

Nice and tidy. One place to rule them all.

But there's a catch. What happens when different parts of your code need slightly different logic? That one helpful function quickly becomes a bloated mess of if-else gymnastics.

Write Everything Twice

WET is like a programmer in a fancy tuxedo at a code review, sipping espresso and saying:

“Relax. It’s totally fine to repeat yourself. Just make sure your teammates don’t cry trying to read it.”

Write Everything Twice proudly welcomes a little duplication. Instead of abstracting everything like you're solving quantum physics, WET says, “Chill, just copy-paste it if it makes things clearer.”

Especially in early development, when features pivot more than your mood on a Monday morning, writing things out twice might just save your sanity.

function sendEmailToAdmin() { /* admin-specific logic */ }
function sendEmailToUser() { /* user-specific logic */ }

Sure, it’s a little repetitive. But it’s also obvious what each function does.

No detective work. No 17 nested utility functions. No crying in the break room. Just readable, understandable code.

Avoid Hasty Abstractions (or Let It Cook)

Coined by Kent C. Dodds, AHA encourages waiting until you see a real, repeated pattern before DRY-ing things up. It’s the wise old wizard of the programming world that instead of jumping on abstracting everything like a DRY disciple on espresso, AHA whispers,

“Patience, young coder. The time to abstract will reveal itself.”

function createAdminProfile() { /* some admin stuff */ }
function createUserProfile() { /* some user stuff */ }
// After a while, you notice a shared pattern...
function createProfile(role) { /* shared logic here */ }

Think of it like dating your code before marrying it into a shared module.

The idea is to let duplication exist temporarily while the codebase evolves. Then, when the patterns are clear and stable, swoop in like a coding ninja and extract that sweet, maintainable logic.

When to use what?

Scenario	DRY	WET	AHA
Obvious, repeated logic across files	✅	❌	⚠️
Similar code that may diverge later	❌	✅	✅
Early development stages	⚠️	✅	✅
Shared business rules	✅	❌	⚠️

Final Tip

Good developers write DRY code.
Great developers know when not to.