Dan Abramov completely changed his life with just 99 lines of code when he created Redux.
Ryan Dahl changed programming history by introducing the world to NodeJS.
The two stories have a few general things in common:
- Both are JavaScript related.
- Both were created by talented and motivated individuals.
- No one asked them to do it.
The two side projects, one big and one small, initially were just ideas two people thought were cool.
Both developers took their ideas one step further. They developed their ideas into working projects. And then they shipped those projects.
There’s more to both stories, I’ll elaborate in a few moments.
StackOverflow Says We Love Our Side Projects
The average developer spends more than 7 hours per week coding on the side.
This is just one of the facts uncovered by this year’s StackOverflow annual survey. And for some reason, I kept thinking about it.
The fact that 91.7% of us have active side projects is astounding.
Stack Overflow Developer Survey 2015 StackOverflow end of 2015 survey
We all of love to code. But that’s what we get do for 9+ hours a day, 5 days a week. And a lot of us have jobs that demand even more.
Our love of code doesn’t explain these numbers. We must be getting a lot more from our side projects than just another chance to code.
I know this to be true, because I felt it.
When I’m working on my side project, I get this feeling of “Flow” I don’t get anywhere else. The fun starts from that magical moment you hit the “New Project” button, and reaches its peak the moment you type git push heroku master .
But besides having a blast working on our side projects, what else can we gain?
A Learning Experience
Being a self-learner is the most important skill a JavaScript developer can have.
We used to say JavaScript books became outdated before the first edition was out of print. Today, JavaScript churn is so crazy that JavaScript eBooks become outdated before the author even has a chance to export to pdf.
If you don’t believe me, ask Juho Vepsäläinen, the author of SurviveJS. It’s an awesome eBook which covers React, webpack and the Alt Flux implementation.
Alt? What’s Alt?
Alt is a Flux implementation which was popular right before the Redux tsunami hit. Alt seems like a distant memory now, lost in the sands of time. An ancient relic of the Flux Wars.
We’re talking about 8 months ago… An eternity in JavaScript time.
SurviveJS now also provides examples in Redux. I’m sure that by the end of the year a large part of SurviveJS will be updated when someone finally codes a better webpack.
“Any fool can know. The point is to understand.” – Albert Einstein
Even the best, leanest JavaScript related eBooks out there are struggling to keep up. Trying things out for yourself becomes even more indispensable.
Learning by doing is the most important benefit of the JavaScript side project. It allows you to “kick the tires” and “get a feel” for whatever it is you’re playing around with.
I’ve been using the “mini side project” technique for years. And it’s been working great for me.
Every time I learn something new I do two things:
- Follow the step by step guide which usually accompanies most tutorials. For example a todo list app.
- Create my own “mini side project” which is similar to the to the guide, but still different enough to make it interesting.
For example, alongside the todo list app I would work on a “favorite movies” app. Which on top of being a “list of things” would also require me to fetch data from IMDB, and display images and formatted text. Taking it one step further I would also include an autocomplete box.
The advantage of this approach is that it makes sure I don’t follow into the “monkey see, monkey do” trap. Falling into this trap means you end up following along the tutorial step by step without understanding completely what you’re doing.
A JavaScript side project could get you hired
Forget for a second about the Cinderella stories where your side project becomes a major success and you get an awesome job working full time on it.
Showing up for a job interview with a relevant, demoable side project changes the whole experience. For both you and the interviewer.
At some point during the interview, you casually slip in something like “That reminds of this thing I’ve been coding on the side”. Your interviewer will ask “what is it about?” followed by “can you show me?”.
You will then be grilled about every tiny detail and decision you’ve made about your side project.
Which is a good thing.
You know your side project probably better than any other thing you’ve worked on. And as long as the project comes off as decent and you can effectively defend your design, you’ll leave a great impression.
Interviewers love this too. They know you’re not misleading them, making something up or blowing things out of proportion. They can actually see something you created and they know you’re the one who created it.
This is especially effective with interviews for startups, which tend have more well rounded technical interviews. This is opposed to larger companies which tend to have rigid and narrow whiteboard programming interviews.
Nonetheless, If your heart is set on working for a giant evil corporation, this book will probably be the most useful book you’ll ever read. Just don’t skip the part about inverting a binary tree.
Creating A JavaScript Side Project “Just for Me”
The vast majority of side projects fall into this category. As developers, there’s nothing that gives us more joy than using something we created.
I have a colleague we will call Orlando. Orlando runs the lighting system of his house with his side project. He controls several smart lightning bulbs by running a Node server on a Raspberry Pi machine.
The UI is of course built with React + Redux because he needs performance and scale 😃
Orlando’s eyes light up whenever we talk about his smart JavaScript home. You can feel his excitement whenever he shows you how he presses a lightbulb image on his screen and the lights turn on.
Orlando is currently only taking feature requests from his wife.
I also have a “just for me” side project. I’ve been playing a FreeCell Solitaire game once a day for as long as I can remember myself. I thought it would be pretty sweet to create an implementation of my own.
An exciting and earth-shattering project, I know.
But when I’m finished creating my obscure side project I still intend to ship it. Simply because it’s a better option than to not ship it.
But what exactly does shipping a side project mean?
Sharing your JavaScript Side Project with the World
Can you imagine what would have happened if Ryan Dahl didn’t share his weird idea with the world?
I’m sure there were plenty of people back then that would have told Ryan his idea is dumb. That running an event loop based, JavaScript server on the Chrome V8 JavaScript engine is the stupidest idea they’ve ever heard.
They would tell him it wouldn’t work, it wouldn’t scale and he’ll just end up making a fool of himself. The sad thing is that some people don’t even need others to tell them all those horrible things, they tell them to themselves.
But Ryan, who seems to be a shy individual, had a burning desire to share his creation with the world. He didn’t just publish it on GitHub and pray the world would somehow find out about his creation, like so many of us do.
On November 8, 2009, Ryan gave an awkward talk at JSConf EU. A talk that would change web development history.
On that day he did something I’m going to assume was out of character. He stood in front of some of the brightest minds in the JavaScript world and demoed his mostly functional version 0.1.0 side project. Also known as NodeJS.
At that moment, Ryan shipped node.js to the world.
“OK so now I have a demo for you. I wrote an IRC server in node, just a hack really. Just to demonstrate what you can do.
Maybe this will work maybe this won’t work but let’s try to go to irc.nodejs.org and go onto the #node.js channel.”
Ryan Dahl, first ever live NodeJS demo
Imagine what would have happened if Ryan waited until everything was “just right” and “worked perfectly.” Deciding to give his talk “the next time.” Procrastinating indefinitely.
Perhaps if he did, PayPal would still be running on Java today.
Small side projects can have a huge impact
Dan Abramov wrote 99 lines of code that changed his life and sent a shock wave throughout the JavaScript community. Something he never intended to do.
Dan wanted to give a talk about “Hot reloading and time travel” without even knowing how to achieve the “time travel” part. He was just passionate about a subject he first encountered in the Elm Architecture.
Dan not only introduced his specific idea but also brought functional programming to the center stage of the JavaScript universe. The fact that more and more JavaScript developers are starting to think in terms of side effects and pure functions is a blessing. Regardless of how you feel about Redux.
Dan had a spark of genius, motivation, and the right attitude. He shipped his idea. Redux now has 15,000 stars on GitHub and is the 48th most popular JavaScript project of all time.
Dan Abramov summarized why he shipped Redux very nicely at the end of his talk:
_“What I wanted to say is that, these are not new things. I did not invent them. Some people will tell you that they existed 30 years ago, and maybe they’ll be right. _ But we’ll never find out if no one talks about bringing cool functional techniques to JavaScript. Because if you learn a cool programming language like Elm or ClojureScript, you stay there. __ It doesn’t have to be this way, you know, you can share your knowledge. Please do. Because you can do functional in JavaScript. You can bring functional programming to the mainstream and do really cool stuff with it.”
Shipping Your Side Project: The Scary Part We Tend to Skip
I’ve been talking about shipping quite a bit throughout this article. I wanted to break it down a little.
Shipping is the act of standing up on an imaginary table and shouting at the top your lungs “Look world, I made this.”
Shipping is scary. When we were creating our “Just for Me” projects everything was fun and mellow. But if we ship our project to the world we might get criticized, we might look foolish, we might fail.
The part of our brain which is responsible for all of those scary thoughts is often referred to as “The Lizard Brain”. It’s in charge of only 2 things: survival and procreation.
To do so, it only needs to make you feel four things: hungry, selfish, scared and horny. Everything else doesn’t matter.
For our lizard brain, receiving a nasty comment or a mean tweet raises our primal rejection instincts. It immediately raises our alarm bells.
Every negative social input makes your lizard brain think that you’re about to be thrown out of your tribe into exile and die of starvation.
The lizard brain will activate anytime you’re about to do something new. It will say something like: “You survived this far without doing this new thing!!! Why start now?! Are you crazy?! Don’t kill us!!!”.
Before we ship something new, our rational mind is starting to get all of these crazy signals from our lizard brain. Since no apparent danger is in sight, our rational mind still needs to make sense of all of these warning signals.
That’s when you start thinking “I need to make sure everything is perfect, I’ll finish it tomorrow.”
To learn more about your lizard brain, watch this talk by Seth Godin, or read one of his books. I can honestly that Seth’s unique take on life motivated to start this site.
Let’s say for the sake of argument that I’ve convinced you shipping your JavaScript side project might be a good idea.
What will happen after you ship?
The world reacts to new things in 3 different ways
The responses the world will throw at you can be divided into 3 complex scientific categories: Boo, Meh, and Wow.
1. Boo
This is by far to the most uncommon response to anything new. This happens when you create/say/do something and people actively Boo you for it. This what our lizard brain fears the most.
We perceive being Boo’d as much more common than it actually is, do to the way our lizard brains are wired.
Before shipping always ask yourself “Does this thing I’m about to do has the potential to affect my life in a significantly negative way?” Be honest. And if the answer is no, which is almost always the case, ship.
2. Meh
“Meh” is a much shorter way of saying “I’m indifferent to this new thing. Whether or not it continues to exist doesn’t matter to me”.
We respond to 99.99% of new things with “Meh.” At least according to a Stanford research I made up in my head and doesn’t really exist. But I’m sure it’s somewhere along those lines.
And since we don’t really notice the number of times we respond with “Meh” reactions, we tend to believe these reactions are a lot less common than they actually are.
I found a nice example of this point at stats.js.org. The site lists the top 10,000 JavaScript GitHub repositories. According to the site’s algorithm, the top 10,000 JavaScript projects are Wow projects and are worth listing, analyzing and filtering through.
Everything below the 10,000 mark isn’t worth the computing power it takes to process the results. In short, Meh.
10,000 projects might sound like a lot of Wows until you realize there are 2,010,058 JavaScript projects on GitHub as of this writing.
A quick ratio check shows that js.stats.org considers only 0.5% of JavaScript GitHub repositories as Wow repositories. Meaning that it thinks 99.95% Javascript GitHub repositories are “Meh.”
My made up Stanford research was only slightly off.
3. Wow
Watching React Native work for the first time was a Wow moment for the React community. Watching Dan Abramov time travel through a to do list achieved the same result. Watching Ryan Dahl running a JavaScript server on top of V8 made the entire programming industry go Wow.
For me, having (awesome) people share one of my articles over 1000 times was a Wow moment. For Mashable.com however, that amount of shares is reached effortlessly.
There are of course different levels Boo, Meh, and Wow, which are spread across a continuum. And one person’s Boo could be another’s Wow.
A project you feel is Meh could Wow the world if you only gave it a chance.
Your Turn
There are a lot of great reasons to develop a JavaScript side project. You could learn something new, upgrade your career, and have a lot of fun while doing it.
But please when you’re done, share your project with the world. “Done” doesn’t mean perfect. You know you’re done when you created something that sort of works, and overall it’s good enough to make you smile.
Help the world find another Wow in the sea of endless Meh. Ship your JavaScript side project.
So, what will you create?