Design patterns are not spells to memorize They are tools for solving specific pain in your code One of the biggest mistakes I see developers make is collecting design patterns like trophies They learn Singleton Factory Strategy Observer Decorator Then they try to use them everywhere But patterns were never meant to be starting points They are responses to problems When you apply a pattern without understanding the pain first you do not improve the system You increase complexity Over engineering usually looks like this → Adding abstractions before they are needed → Creating interfaces with only one implementation → Introducing layers that do not solve a real constraint → Optimizing for flexibility that nobody requires → Making code harder to read in the name of being advanced Good engineers diagnose before they prescribe Before choosing a pattern ask yourself → What specific problem am I solving → What pain exists in the current design → Is duplication actually harmful here → Will this change simplify or complicate the system → Does the team understand this level of abstraction Patterns are valuable because they encode proven solutions But blindly applying them creates new problems that did not exist before The goal is not to show you know patterns The goal is to reduce complexity and improve clarity Simple code that solves the problem is better than clever code that impresses interviews Have you ever over engineered a solution because you wanted to use a pattern Or have you worked in a codebase where patterns made everything harder to understand Share your experience below Follow Nelson Djalo for practical lessons that help you think like a real software engineer #coding #softwareengineering #programming
That's similar to using agile to everything, whether it's useful for the project or not
I've seen over-abstraction make code more difficult to debug and problem solve. I've also seen an incorrect pattern applied when a different pattern addressed the problem better and more cleanly. Usually, once I'm inside a component of volatility (following Righting Software by Juval Löwy), I look at the business use cases applicable to that component. I look at the overall picture and find a design pattern that expresses those steps, then drill down further deeper until I get to the single business unit of function. Sometimes I don't know what the pattern is until I start coding more features and seeing the complexity grow. At that point, stop drilling down or you'll over-abstract. Not every else statement or private method is a sin if chances are strong it won't ever increase in complexity. You won't gain anything ... but I do leave comments addressing the issue with a mention to switch to a pattern if complexity increases. I treat software code like an English paper. Nobody writes anything once and gets it right (unless you're Jack Kerouac). Also, we gotta let go of functional decomposition. It only works until you start adding features.
Here is a recommendation for the topic. It changed the way I look at software patterns: https://www.youtube.com/watch?v=F0UhBEQzuKA&t=1942s&pp=ygUoQXJjaGl0ZWN0dXJlIGFzIGEga25vd2xlZGdlIGtldmxpbiBoZW5ueQ%3D%3D
Another pressure is the idea that complex code means smart engineering. Especially with AI and modern stacks, people assume if the solution is simple it must be naive. So developers add layers, patterns, and abstractions just to make the system look “advanced”. But real engineering skill is often the opposite: removing unnecessary complexity and making things clear.
Abstractions added before real constraints emerge, like single-implementation interfaces, turn the codebase into a maze for the team. When overused, design patterns stop being a shared language and become noise that impedes collaboration. Clarity and alignment must take precedence over theoretical flexibility.
Template Method to kill duplicated execution flows. Strategy to kill conditional chains picking different behaviors at runtime. Both saved me a lot of headaches. I applied them when the pain was real.
Can you also make a video thinking in design patterns. thanks for sharing 👍
How are they applying with spring boot as beginner it bit confusing 🫤
I wonder if it’s time to rethink how we teach design patterns. We spend so much time on the "how-to" but rarely discuss when NOT to use them. The result? Systems that are over-engineered for flexibility where it’s not needed, yet incredibly rigid where actual changes are required. Has anyone else dealt with this kind of "architectural astronomy," where the code is drifting in deep space while the actual business needs are still stuck on the ground?