Design Patterns: Don't Let 'Templates' Chain Your Engineering Mindset

Hello folks,

After yesterday’s post, I got quite a lot of positive feedback about the trade-off mindset. So today, let’s talk about something closely related — those so-called “templates” that others have already created for us to follow.

Most people call them Best Practices. But are they really always as good as advertised?

Here’s the truth: If you’re working in a creative field like IT, never let predefined patterns limit your thinking. And this is especially true for Design Patterns.

The Trap of Looking “Smart”

About 3 years ago, I was just getting into the dev world. I had a friend who bragged about memorizing almost all Design Patterns. I thought he was insanely good, and I started chasing that.

I even bought Head First Design Patterns and treated it like my bedtime book.

Back then, my standard was simple:

The more patterns you know and apply, the more “pro” you are.

In my final school project, I threw in a bunch of patterns just to make it look “professional”.

But after real-world experience — getting crushed by deadlines and debugging my own “clever” code from 6 months ago — I realized a painful truth:

Design Patterns are vitamins. But overdosing turns them into poison.

When Do Patterns Become “Chains”?

I’m not saying patterns are bad. They help keep systems clean, improve decoupling, etc. But they only work when applied in the right context.

Don’t use a pattern if you can’t answer these 3 questions:

1. Does this problem actually exist?

Are you building a villa foundation just to place a chicken coop on top?

2. What’s your team size?

A team of 2 building microservices with a dozen patterns? That’s not architecture — that’s self-inflicted complexity.

3. Are you over-optimizing for the future?

You’re abstracting for the next 5 years… but your product might not survive the next 3 months.

Senior Decision Framework: The Rule of Three

Instead of blindly loving or hating patterns, a real Senior uses simple decision rules.

1st time:

Write the simplest code possible (KISS). Let it be a bit “ugly”.

2nd time:

When similar logic appears again, don’t rush into abstraction. Copy-paste it again.

Why? Because you still don’t have enough context to know what’s truly common.

3rd time:

Now it’s justified to refactor. You finally have enough real examples to extract the right abstraction.

Remember: The cost of a wrong abstraction is far higher than duplicated code.

A Practical Example

❌ Over-engineered approach:

class ShippingFactory {
    static getStrategy(type) {
        if (type === 'domestic') return new DomesticShipping();
        if (type === 'international') return new InternationalShipping();
        throw new Error("Unsupported!");
    }
}

const strategy = ShippingFactory.getStrategy('domestic');
const fee = strategy.calculate(10);

✅ Practical (KISS) approach:

function calculateShippingFee(type, weight) {
    const rates = { domestic: 1000, international: 5000 };
    return weight * (rates[type] || 0);
}

In the first approach, you touch 5 files to change one piece of logic. In the second, it takes you 5 seconds.

If your app only runs in one country for the next 2 years, that Factory is nothing but technical junk.

Conclusion

Design Patterns are meant to serve you. You’re not meant to serve them.

A great engineer isn’t the one who memorizes the most patterns, but the one who knows when not to use them.

Don’t try to look smart with complex structures. Show your skill by turning complex problems into simple, maintainable solutions — so your teammates can understand and modify them without calling you.

So today, ask yourself: Are you adding patterns just to feel smart? Or are you actually solving real problems?

It depends. But don’t let short-term “coolness” turn into long-term pain.