TL;DR:
It's Addy Osmani. He wrote a book called Learning JavaScript Design Patterns. He made me infinitely better because I learned the underlying principles of programming. Frameworks, APIs, Languages come and go. Programming principles and design patterns are everlasting.
The Infinite Game
I recently saw Simon Sinek speak in NY to launch his new book called The Infinite Game. The core concept of an Infinite Game is to play for longevity - have a vision. Win the war, not the battle. A Finite Game has a predefined, fixed set of rules that all players must abide by. In an Infinite Game, the rules keep changing; the players come and go.
One of the five practices to successfully play in this Infinite Game is to have the capacity for existential flexibility. In other words, arm yourself with universal knowledge so that when the rules change, when the players come and go, you're still a viable player in the game. How does this concept apply to programming?
The Game was Changing
It's 2011. I launched a streaming video startup. At the time, I was weighing which tech stack to use. Mind you, the next evolution of libraries and frameworks were brewing around this time. JS frameworks like Backbone, Ember, Angular were just coming on to the scene. jQuery was ubiquitous. ES6 did not exist. Internet Explorer was still a thing to work around. CORS rules were very loose. SASS was starting to be used more heavily. Node.js was starting to gain meaningful adoption.
The market was changing and changing quickly. It was clear that there was a huge appetite for speed - speed to market, development, production, deployment. Minimum Viable Product (MVP) became a religion.
As a startup founder, I also wanted in on the speed and I thought that with regards to technology, the aforementioned players were the way to go.
Permission to Launch
Suffice to say, I was overwhelmed and confused. The industry seemed to be diverging instead of converging. There were standards set forth by W3C and ECMA, yet these popular frameworks were doing things differently. New ideas were being introduced and pushing the limits - sometimes for the good, sometimes for the bad.
One day, I stumbled upon this unassuming, black and white website. It looked like this:
One of the first sentences that I read:
"Another way of looking at patterns are as templates for how you solve problems - ones which can be used in quite a few different situations." - Addy Osmani
Sold.
Exactly what I was looking for. How do I build an application that is scalable enough so that pieces of my code could solve more than one problem across different situations? How do I get fast?
As I read further and learned about patterns, anti-patterns, structure, and specific and trusted patterns like Revealing Module, Decorator, Facade, Observer, I started to understand that there is no one gotcha technique, library, framework; there is more than one way to solve a problem.
"...it’s not the number of patterns you implement that’s important but how you choose to implement them. For example, don’t choose a pattern just for the sake of using ‘one’ but rather try understanding the pros and cons of what particular patterns have to offer and make a judgement based on it’s fitness for your application." - Addy Osmani
I can use more than one technique depending on the situation at hand. Wow - the world is my oyster. Now armed with universal knowledge, more confidence, and a greater understanding of techniques and when to use them, Addy Osmani gave me permission to launch my startup using --- JavaScript. I felt free and empowered.
"You might not think that programmers are artists, but programming is an extremely creative profession. It's logic-based creativity." - John Romero
Speed
I got what I wanted. Speed. Speed in development by being able to reuse code. Speed to market by being able to write with less duplication and looking to my previous solutions for answers. Speed in onboarding team members because now my code was easier to read and structured meaningfully. My 5,000 line file (!!) was broken up into bite-sized pieces.
Existential Flexibility and Longevity
Fast-forward a few years to 2014. Angular 2 was announced and caused an uproar. The JavaScript landscape was changing again. Some of the most used frameworks began to lose traction. Players were going. New players were arriving:
I started to question our code and architecture. Should we actively adopt these new frameworks? A bunch of large, successful companies were using them, does that mean we should too?
Changing Players
I came to the realization that what was happening now was deja vu. It happened to the generation of frameworks and libraries 3 years ago, and happened to the frameworks and libraries that came before them and so on. And with Addy Osmani in mind, I realized that developers had simply discovered patterns and recurring problems, sought ways to make better programming decisions and then released their findings in a thing called a framework. This time though, they were called React, Vue, etc. Soon to be followed by names like Next, Svelte, litHtml, and so on. SCSS, LESS. Django, Laravel. They were all just trying to help us because they had experienced their own pains at one point.
If you dig into the code and principles of these frameworks, you'll realize that they are all applying design patterns - some more prominently than others. Observer is a big one. You'll also realize that they are essentially someone's abstractions, opinions - written in a "pure" language like JavaScript, Python, etc. The "magic" was revealed and I realized, that the code that my team and I had written was aligned in principle to such frameworks.
Longevity
We continued to improve the application but because of a number of factors, we were unable to adopt new and emerging standards such as ES6 quickly. Our customers were mostly in the enterprise space which meant that they were using older browsers (IE) and were slow to adopt newer technologies and devices. Our code base stayed on ES5 until my departure in late 2018. Yet, our product was still working. Our customers were still happy. Our development was still fast and scalable. We were still building new features.
New Standards, ES6
The rules of the game had changed yet again. The new and better way of building things was now over there. So there is where people went. ES6 came along in 2015 and established new standards. Much of these new standards, it turns out, were inspired or derived from the frameworks and libraries that came before it!
Browsers changed. Mobile devices became faster. Support for modern language features arrived quickly. Yet, the underlying principles remained. Design patterns remained. ES6 introduced classes, which is just syntactic sugar for prototypical inheritance. Modules were introduced, which is simply extended support for the Module Pattern described by Addy Osmani in his book.
New Hotness and the Infinite Game
Now the hot new thing is Functional Programming and there are some proponents of this paradigm that view it as a religion. All of a sudden, nothing else matters and everything else is wrong. We saw this play out when React introduced Hooks. All of a sudden, if you were still using classes, you're now illegitimate. This is playing with a Finite Mindset inside an Infinite Game.
There will always be a new hotness. It's the nature of the Infinite Game of the software development industry. There is no winner or loser, only ahead and behind - Simon Sinek.
Addy Osmani, Mentor to Many
Addy Osmani equipped me with knowledge that rises above trends and stands the test of time. I can learn new languages and syntax quicker and more efficiently because of my understanding of principles and patterns used. He gave me the confidence to build applications without feeling constrained by certain rules and regulations (i.e. you must ALWAYS do it this way). He instilled in me an Infinite Mindset so that when players come and go, trends arrive and disappear, I am able to remain viable, ready to learn, able to refactor with minimal impact, and build applications that stand the test of time.
Final Thoughts on Mentorship and Thinking for Yourself
Addy Osmani was my mentor and he didn't even know it. He inspired me, gave me confidence and tools, but most importantly, he gave me the freedom to think for myself. The freedom to decide how best to solve my and my team's problems.
There is a big difference between thinking for yourself and reinventing the wheel. Sometimes, the wheels that are in the market just don't fit your requirements and you'll have to make a new one and that is absolutely OK.
Here is a link to Addy Osmani's book, Learning JavaScript Design Patterns - https://addyosmani.com/resources/essentialjsdesignpatterns/book/.
Top comments (12)
@addyosmani is inspirational to many
That's an indeed amazing book and @addyosmani is an inspiration for all developers. I had a chance to work with him on a few projects and it was nothing, but only a positive experience.
I even got a chance to refactor this book, this is my PR: github.com/addyosmani/essential-js.... Not sure if it's gonna be merged in the book, but it was an amazing experience and it gave me a lot of new knowledge back in the days.
Loved the article, I try teach this concept to others who get lost in the hype of new buzz words like a few years ago with big data, but the question is does your company actually qualify for big data? ......and now Blockchain, where one must realise that DLT is not for every problem out there.
Well done, great article!
How relavent would it be to read it today. I've read that his book is now a bit dated.
Still worth reading in my opinion. Syntax is outdated, but the principles are still sound.
Thanks for the share <3
Just ordered it on Amazon!
I really enjoyed reading your article. Thanks a lot.
I read his design pattern book as well. Made me a better JavaScript programmer @addyosmani
Really liked the way you presented above article. I have read many articles of @addyosmani and felt the same. But you expressed it. Good job @eaich .
Love that book. One thing I noticed is that after reading first time, I found myself re-reading it again a year later and I think I plan to re-re-read it again next year.
Great article!