I find that the more senior you become, the less you rely on software design patterns.

Juniors often think that learning design patterns is some kind of career hack which will allow them to skip ahead a decade of experience... There is some utility in many design patterns but the problem is that juniors often miss the nuance and the motivation behind the patterns and they tend to misuse them; often creating more complexity than they would have created had they not used design patterns.

There are situations where design patterns may be useful but they're much more rare than most people think. A lot of juniors seem to think that every problem requires them to apply a design pattern from their toolbox. They try to frame every problem within the constraints of design patterns that they know. This can create problems.

In fact, there are many coding patterns which are far simpler than 'design patterns' and much more useful, but nobody talks about them because they're too trivial to discuss. For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding. In general, knowing what data structure is most appropriate for various scenarios is a game changer... But still, don't abuse. Basic data structures like arrays are fine most of the time.

Anyway, it's good to absorb the wisdom behind some design patterns but you should not try to fit every problem to them and dont say stuff like "For this problem, I applied Design Pattern X" - If you do, senior engineers will know you're a junior. If you use a design pattern correctly, it will probably not look exactly like in the textbook. It's kind of hard to give it a name. It may be a mix of patterns. It's the principle that counts. Reality is too complex for rigid design patterns.

On the other hand, some design patterns are too common and obvious to deserve a name. For example, the factory pattern is super common... I use it all the time but it's so basic and obvious that I will sound like a total noob if I go around calling my function "socket factory pattern"... I will call it "Utility function to obtain a socket" or something. I will never refer to it as a factory pattern, it's a bit cringe.

I see it as a common vocabulary to talk about tools. It's simpler to say "I made a singleton" than to describe it.

Just like we have words for a nail, a screw, a hammer. If you had to say "I used a tool that I find works well with nails", that would be annoying and ambiguous.

Now of course, if you quickly screwed something with your swiss-army knife and a junior came and told you that this is wrong, because you should always use a proper screwdriver, and therefore you should rent a car and drive 30min to go buy it right now, you would kindly tell them to fuck off. Doesn't mean that there is no value in the concept of a screwdriver itself.

I agree with the first half as it echoes my experience, but the second half hasn't been my exp.

To talk about design patterns as not as useful, only to then mention big O notation seems strange to me unless you are in a context where performance is critical?

Worrying about O(n) IME is far less important than choosing the right architectural pattern. O(n) issues are usually observable via metrics or QA and are typically straightforward to fix. By contrast, recognising that your pattern choice is wrong is harder (since it manifests during dev rather than in prod) and takes more effort to rectify.

I also disagree that patterns don't deserve a name. I have found it very useful when discussing with both seniors and juniors to have a common name for a pattern being described. Seniors known instantly and it can be helpful to have a resource to point juniors to if they aren't familiar. I have also found it useful when English isn't the first language.

I do agree that seniors don't typically try to fit standard patterns to their problem in a way that a junior might, that's a fair point.

> For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding.

This is a "hash join" in relational databases. You can see it in the query planner output of at least postgres.

I wouldn't say it's cringe. A factory is a factory. Calling it that in the code may not be the best idea, but having the shared vocabulary is nice. Basically, patterns work well when they're descriptive rather than prescriptive.

There are two cases that are unique though: state machines and visitors are so much things on their own, that you'll use those names almost every time you run into the pattern.

> For example, I've seen people write code which relies heavily on design patterns but then that same code uses an O(n^2) nested loop to find items that are common between two arrays. There is a simple 'pattern' you can use to store the items of the first array in a Set or HashMap and then finding common items is O(n) because Set and HashMap lookups are O(1)... Very useful pattern but I don't believe it has a name. I use it literally ALL the time. The idea of storing intermediate state in some kind of HashMap is a game-changer IMO but there's no name for that pattern of coding.

Isn't this called 'dynamic programming'? It's actually a habit people should pick up when grinding leetcode.

the actual software design patterns, unbiased by language/particular-usage, are subtle. i would go as far as say that there are also "design-patterns"-usage patterns.. and those might be even more subtle. e.g. what is/constitutes "interpreter", and when to use one, and when/if one is being used behind-the-scenes. Sometimes it is a single piece that is easily pinpointable. Sometimes a whole (sub)system behaves like one (e.g. event-sourcing stuff) but it's not easily cut into this is this, that is that.

But anyway, this site seems javascript/frontend wanna-bees oriented.. please don't take those tutorials as mantras-to-follow-at-any-rate. See if you can take the knowledge and move on.

A very good book, besides the GoF one, is the "Organisational patterns book by James Coplien, Neil Harrison" [1]. It contains some of the GoF *plus* all the non-technical ones, and they are bundled together - as software making is not just the coding.. i have the list of those patterns essences (patlets) extracted, here the link - https://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patle...

edit: it's from ~2003-5 and images are missing. May need to scan them from the book. Closest i found is [2], at least to get some idea

[1] http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/

[2] https://www.scrumbook.org/book-outline/history-of-the-patter...

For your example, if both lists are small enough, the constant factor on the cost of creating the hashmap eliminates any advantage you could have. Anyway, it's not like most places were I've seen a nested loop used for search the developer had cared. Today I am in a bad mood.

I have to touch some of the most unnerving modules in a legacy project and everything is a trap. Lot's of similar repeated code with ugly patterns and some big brain trying to hide the ugliness with layers and layers of indirections and inheritance, and calling it clean because there is a factory class. The biggest joke? each implementation have a different interface for key methods, so later you to check what instance got created.

I want to keel myself. Anyone could assist me in a seppuku?

What about the social / communication aspect ? Having a common vocabulary of pattern may help reduce cognitive load when reading others code. Just a soft opinion because I assume it's the reason frameworks and conventions help teamwork. Less per-context custom solutions.

> Very useful pattern but I don't believe it has a name.

This is an instance of “use the right data structure for the job”. To me it has little to do with architectural design (where design patterns live), but it has to do with algorithmic design.

For webdev especially everything I do is basically singletons... For UI state management its just perfect and that's about the hardest thing in web dev. Also easy to recover state with, in a SPA if a user refreshes the site. Or control whether a modal is open or not. Easy to centralize logic too... Never looked into any other patterns as a lot of them seem like bloat.

Agreed! The problem is that some 'seniors' never cared to learn patterns in the first place. That’s a huge problem for frontend, where we have increasingly complex architectures and people with very little experience with design.

Even some principles aren't known. I always recommend the book Head First: Design Patterns. It's in Java, but the lessons can be applied in every language.

Unfortunately, we are in a 'post-knowledge' era... I don't know how we can keep things up at this pace.