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 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.
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
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.
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
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.
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.
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 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?
Can you imagine what would have happened if Ryan Dahl didn’t share his weird idea with the world?
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.
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 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 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.
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.”
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.
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.
“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.
Everything below the 10,000 mark isn’t worth the computing power it takes to process the results. In short, Meh.
My made up Stanford research was only slightly off.
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.
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.
So, what will you create?