Software Engineering more of a craft. The only way to learn is by continuously practicing, collaborating with others and studying other people's code deeply.
Design Patterns are not a catalog of recipes that you can use to put together a functioning system. They are instead an attempt at creating a "common language" of sorts for some common concepts. They don't really teach you anything about good software: they only allow experienced people to communicate well. The authors themselves have stated: "design patterns are descriptive, not prescriptive".
What one has to learn, instead, is the foundational knowledge that was used for building those "patterns and guidelines", and even for other things like SOLID. And dare I say and even functional programming, OOP and procedural programming itself. For example:
• Why you don't want tight coupling (foundation of lots of patterns and architectures)
• How to make program state predictable and why it's important (foundation of both OOP and FP, including encapsulation and immutability. And also of some patterns like CQRS)
• How to design good interfaces/APIs on all levels (functions, classes, modules, libraries, services, programs, companies)
• How to understand the cost of hidden dependencies (not talking about libraries, more like "functions that call other functions" or "classes that depend on other classes". This is Joe Armstrong's banana-gorilla-jungle problem)
• How to make functions/classes/modules that you can change without requiring cascading code changes in the rest of the program (again this has to do with coupling)
• How to make programs predictable in general (the most important business wise)
So you’re saying because software is a „craft” you can’t write down ideas how to do it better? Your bullet points are exactly this. The only thing that makes them different from „patterns” is you didn’t give them a name.
I never said anything of the sort. You asked how one learns and I answered: not with patterns or recipes, but rather with practice and observation. Even if you memorise dozens of recipes you still ain't a chef. To be a chef you need to know how to prepare, combine, modify and even come up with those recipes. My bullet points are not patterns or guidelines you should follow. They are examples of the foundational knowledge you need to "come up with the recipes".
Parent describes the experience and understanding of why certain methods of building software work better than others. A pattern, on the other hand, is more like a recipe that can be followed without knowing whether it is actually appropriate for solving a particular problem.
Not the OP, but no. Those are concepts that are important that need to be understood through experience and applied judiciously wherever they help (which is lots of places) but never by rote and not where an alternate approach is better.
That's quite distinct from design patterns, which are usually taken as gospel that needs to be followed for its own sake.
My karate sensei used to say that while all kyu ranks must follow the katas with extreme precision, the higher dan blackbelts have absorbed the knowledge and can ignore and innovate.
In that sense design patterns are like katas. Training wheels, but not an end-goal.
You already got a very solid reply. I'll add only one prescription that I found true in all my ~20 years of career:
Write code in a way that everybody can understand it, even managers.
That's it. There's no magic. Code is read MUCH more often than it's written. You have to optimize for it being readable.
This does NOT mean the shortest possible code. I've seen people go to that extreme and it never ends well. But it also doesn't mean every variable has to be called "user_in_a_context_of_private_temporary_login" either.
Truth is, writing understandable and readable code as a skill goes well beyond programming. You will find the same skill in well-articulated presenters, book authors and lawyers.
So just this one advice should be your guiding star: write your code as if you will have a stroke tomorrow and will suffer amnesia and you would still be able to understand your own code very quickly afterwards.
Well, this is bascially what DDD proposes. To write code that reflects the domain, so even your manager understands it. But for some reason, when you call it by a name, people start saying you don’t need those dogmatic patterns. That’s my point.
Not what I observed. When DDD is mentioned, a lot of people want to abstract the entire Universe just in case.
DDD sadly often goes hand in hand with a ton of enterprise Java-like practices that never ended well for anyone applying them. It's one of the collective delusions that's apparently too persistent to disappear by itself.
Resisting the temptation to abstract everything behind factories / config providers / dependency injectors et. al. is a crucial skill in programming and project management. Most people fall to the temptation however.
This is what the article mentions. It’s not about the tactical patterns, but the strategic ones.
DDD is absolutely not about factories or dependency injection. It seems like you mix up Java with OOP design patterns and DDD and treat them all like the same thing. They’re not.
I am not mixing those up. Even when I only had 3-4 years of experience I was very keenly aware they are separate things. But 90% of the people I worked with did mix them up and forced their decisions on me.
I know DDD can be applied sparingly and to produce common-sense code that can be easily read by (almost) anyone and it's what I strive to do for years every working day.
What I was saying is: it's an uphill battle against the mob rule of a lot of people who get easily hyped and lack analytical and critical thinking skills and just blindly apply every single enterprise pattern they've read in a book.
To that end I somewhat agree with the article -- but not completely.
Design Patterns are not a catalog of recipes that you can use to put together a functioning system. They are instead an attempt at creating a "common language" of sorts for some common concepts. They don't really teach you anything about good software: they only allow experienced people to communicate well. The authors themselves have stated: "design patterns are descriptive, not prescriptive".
What one has to learn, instead, is the foundational knowledge that was used for building those "patterns and guidelines", and even for other things like SOLID. And dare I say and even functional programming, OOP and procedural programming itself. For example: