I've been working with javascript for the past 4 years. I'm very confident about my problem solving skills and I can see that my code quality is improving. I try to stay up to date with the community and I'm currently working with ES2015 and React.js. However, I feel like I can't grasp programming design patterns at all. I know where to find resources about this and I have already read books about it. I rely on my senior coworkers to make decisions about the project structure but I have no problem working on it.

Whenever I need to start something on my own I look for these two paths: If I'm using a big library/framework like React.js, I tend to copy what the community is doing; If I'm on something smaller I will be using the module pattern. I know that once I get a better understanding on this subject I will be able to make better decisions, but for now I'm completely lost.

Should I look for superior education on this? Do I need a mentor on this subject? Am I just stupid? Is this really that hard to understand?

  • 6
    In my opinion some languages are more 'forgiving' than others when it comes to the necessity of using design patterns. Strongly typed compiled languages (like Java and C#) are more affected by bad design than weakly typed scripting languages like JavaScript and PHP. Not to say design patterns aren't useful to both, of course. – Matthew Aug 19 '16 at 19:20
  • 3
    Project size also plays a significant role as well. – Matthew Aug 19 '16 at 19:24
  • 2
    @Matthew nitpick I wouldn't necessarily call Java/C# strongly typed... – Jared Smith Aug 19 '16 at 19:37
  • 2
    @JaredSmith true, I often forget the distinction between strongly typed and staticly typed. – Matthew Aug 19 '16 at 20:26
  • 6
    If you're trying to undertsand patterns in general, Stop! There's nothing there! A pattern is a popular solution to a commonly occuring problem, and somebody gave it a name. That's all there is to it. You might find it hard to grasp some specific pattern--I myself struggle with remembering how to effectively use the "visitor" pattern to mimic dual-dispatch in Java--But if you're looking for the secret sauce that links "visitor" to, say "data transfer object," you won't find it. They're just two popular solutions to two common problems, somebody gave them names, and the names stuck. – Solomon Slow Aug 20 '16 at 2:14

Software Design patterns are well-known solutions to well-known problems. The way you understand them is by learning the patterns, understanding how they work, and knowing when it is appropriate to apply each one to your software design.

The way you learn software design patterns is by studying them, one at a time. It's a continuous education process. If you want to reduce the learning footprint, study those patterns that relate directly to the technologies that you are currently using.

Some important things to know about design patterns:

  1. Some design patterns are architectural in nature. MVC and MVVM are examples of such patterns. You use such patterns when you need the organizational and structural benefits that they provide.

  2. Some design patterns are workarounds for deficiencies in programming languages. You won't need these patterns if you use a more expressive programming language, but often you don't get to make this choice. A majority of the GoF patterns are in this category.

  3. Use a software pattern only when you're trying to solve the problem that the pattern is specifically designed to solve. If you're writing an application by stitching together software patterns, you're doing it wrong.

  4. There isn't an existing software pattern for every computing problem in existence. Were that the case, programming would merely be a pattern-matching exercise.

  5. Some patterns are actually anti-patterns. The additional complexity that these patterns introduce outweighs the benefits that they provide. You'll have to decide for yourself, on a pattern-by-pattern basis, which of these patterns you'll avoid.

  • Good answer, although I would disagree with the statement that most GoF patterns are workaround for deficiencies in programming languages. Often, some patterns are better applicable to certain languages, yes, because languages tend to be designed with certain problems and solutions in mind. – Polygnome Aug 20 '16 at 10:59
  • 1
    The Gof patterns are 20 years old. Most of them were created to fix problems with C++, problems that Java inherited because Java is based on C++. – Robert Harvey Aug 20 '16 at 16:15
  • The paradox in this answer is the "well known problem" part. It's hard to understand these "well known problems" if you've never experienced them. – Fuhrmanator Aug 20 '16 at 17:21
  • 2
    Java is not based on C++. javas syntax is inspired by C++, but its certainly not based on it. both languages work pretty differently. From the fact that Java abstact hardware, manages memory by itself, over not having Templates but rather generics etc. – Polygnome Aug 20 '16 at 20:05

Everyone's approach to learning is a little different, and I have no idea what your general approach is, but I do believe your doing yourself a disservice by labeling yourself as "stupid".

Personally, from my observations of what many would call "successful" software engineers, designers etc all have a common theme to their learning: "experience". I believe this to be your "superior education" and you'll learn more quickly from it than buying tons of books off amazon and reading through them (a bad habit of mine).

So, for example, take a GOF pattern like the command pattern and implement it in your choice of language. Understand what benefits it gives you and the drawbacks. The various books on design patterns will explain this to you, but I feel it's better to apply that knowledge practically and learn from it. Don't discount reading material, they have a purpose, but the world of IT is hardly a textbook exercise. That being said, that is my opinion and view of the world of IT and in part, represents own struggles when beginning my career in software engineering. Also, a major issue I see, even with very experienced software developers is impatience and forgetting to enjoy what they are doing. So take your time with what your learning and remember to actually enjoy what your doing, otherwise why bother investing time in it?

In addition, make use of other people's practical experience. There are a plethora of open source solutions, both bad and good and you can learn from them. Look at how they have applied patterns and think about how you would tackle it differently.

So, my general advice is if you feel your approach is wrong, change it. Look at people around you that you feel are learning the material that you feel you aren't grasping and look at what they are doing or even ask them.

  • 1
    I really think that programming is like the chess game. You might have some native talent on it, you might play it all day, but if you don't read some books about chess you can't do any progress and more important you can't appreciate the beauty of the game. – Adrian Iftode Aug 19 '16 at 20:02
  • @AdrianIftode - agreed. As mentioned, I wouldn't discount books, blogs or any reading material, but it's a common problem I've found with people striving for mastery in a programming language/platform/framework etc and seemingly they have done little coding and/or practical effort, but have read every book you can shake a stick at. – Desolate Planet Aug 19 '16 at 22:18
  • @AdrianIftode Well, not precisely. Playing chess without reading books, you can still learn a lot about the game. The only difference is, that you are not learning as fast as you could by drawing on some chessmasters experiences and thoughts. On the other hand, by thinking yourself about certain things, you may stumble across a solution or two that has been totally overlooked by the people who only learn from the chessmasters, and which you might use to your advantage. In the end, I believe a mixture of both sorts of learning provides the best benefit. In chess as well as in programming. – cmaster Aug 20 '16 at 10:03

The short answer is that you don't need them. You can write code without them. As Matthew said in the comments this is particularly true in JavaScript where the language is quite flexible and projects tend to be smaller. But if you've been programming for 4 yrs, I find it hard to believe you haven't stumbled across things that feel repetitive or awkward. Its those areas that you are either rediscovering or missing design patterns.

Example: JavaScript's event system is often inadequate to the task at hand. Don't you ever find yourself wanting to be able to combine or transform streams of events? Or that series of events were first-class values in their own right? You need the Mediator and/or Observer patterns. Need 2-way data binding? Same story.

Brittle prototype hierarchy gotcha down? Mixin/Trait/Subclass Factory patterns to the rescue.

  • 4
    It's virtually impossible to write any non-trivial program without using any design patterns, typically you'll be using plenty of common ones as well. What you don't need is to be able to recognize the patterns that you're using by name. You can write working code even if you can't name all of the design patterns you're using throughout the code. – Servy Aug 19 '16 at 19:38
  • @Servy Design patterns are abstractions, abstractions are not strictly necessary. You can always write out an ad hoc one-off implementation of the underlying behavior...again and again and again. For instance in the example I gave about events, its possible to manually wire up all concerned parties and then change them all every time the requirements change, it just sucks compared to using pub/sub. For subclasses its possible (if wasteful) to manually code in every possibility with a bunch of one-off classes, its just not as good. – Jared Smith Aug 19 '16 at 19:42
  • 1
    Design patterns can get very broad. Often broader design patterns are so obvious that we don't even think of them as design patterns (especially when they have special language support). A loop is a design pattern. Functions are a design pattern. Objects are a design pattern. – Servy Aug 19 '16 at 19:47
  • @Servy if that's how your using the term, then I don't disagree, but I got the impression that the OP specifically meant GOFish patterns. – Jared Smith Aug 19 '16 at 19:50
  • 1
    @JaredSmith Design patterns aren't abstractions. Even if you implement them again and again and again for the concrete problem you have, they are still patterns. You don't need to write a generic Observer class and use that to be using the Observer pattern. Writing concrete Observers and concrete methods to register and notify them is still using the pattern. the hard thing is recognizing the pattern. Sometimes you are using a pattern without even knowing its name, – Polygnome Aug 20 '16 at 11:03

Find a mentor, someone with very good experience to learn from. Ask him question watch his code, submit some code review and try to collaborate with him. This is the best way to step up your coding skills.


  • Collaborate to some simple OSS project you like

  • When there are two way of solving the same problem, always choose the simpler

  • Build some extra experience with side projects where you are free to do all kind of weird error, and you'll learn the design pattern "the hard way"(tm)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.