I love board games.
Even with all of those apps and tablets and virtual reality gadgets running around. There’s something magical about sitting around with a group of friends playing a board game.
But there was one board game I always hated. Even as a small child.
Its name was Candy Land.
I never knew why I disliked the innocent looking board game so much. It only occurred to me recently, after reading yet another article about JavaScript Fatigue.
The author of the article seemed baffled by all of the different frameworks out there, and the different choices JavaScript developers have to make.
I sympathized with the author, JavaScript can be overwhelming. The amount of overhead required to set up a simple React app with JSX is quite high.
But I disagree with the article’s conclusion. Which was along the lines of “Choosing the right framework for me and understanding all of the JS tooling is too hard, I’m just going to use VanillaJS and be done with it.”
This thing is, JavaScript development is only getting more and more complex.
The problems we’re trying to solve with JavaScript are getting bigger, it’s only natural our tooling and frameworks will grow as well.
As JavaScript developers, we can’t hide from the gazillion choices we have to make.
If you choose nothing, you’re going to find yourself solving a lot of problems that have already been solved.
Which you might be OK with. Either that or you’ll take a wrong turn end up with a tasty dish of JavaScript Spaghetti.
Avoiding the problem isn’t the same as solving it though. We can’t close our eyes and hope someone else will make all of the hard decisions for us.
We’ll have to make some choices along the way, this isn’t Candy Land after all.
The Problem with Candy Land
Candy Land is a board game first introduced in 1949. But the game still averages an astounding 1 million copies sold every years.
Candy Land is a colorful board game, filled with memorable characters and lots of distractions. It even has a unique and exciting storyline.
The problem with candy land is that it requires exactly zero player input. You don’t have to make a single choice the entire game. You don’t even have to throw a dice, or choose which card to pick.
The entire game can be summed up with “Pick the topmost card, do what the card says, repeat.” Every player does this until someone reaches the end. The result of the entire game is already predetermined before the first card is drawn.
Candy Land is great at giving you the feeling of participation. But the truth is that the entire game would unfold exactly the same way if you were replaced by someone else.
Or a muppet for that matter.
I used to know a few JavaScript developers who gave me the exact same feeling every time we spoke.
Candy Land Developers
Spotting them at first is hard. They look just like you and me. They even talk the same.
But at some point when you speak to them you come to realize, they will avoid making a decision by all means. They always want someone else to make the call.
I’m talking about Candy Land Developers.
Candy Land Developer – A developer who wishes all of the hard choices will be made for them in advance.
Candy Land Developers always want to use frameworks someone else already put in place.
They always prefer someone else will give their time estimates for them.
They only accept pixel perfect designs. Anything else will be prompted with an email containing 20 clarification points.
They need detailed Product Requirement Documents, and everything else mapped out for them in advance.
Do You Want To Live In Candy Land?
Some of us might believe there’s nothing wrong with being a Candy Land Developer, and avoid decision making altogether. “To each his own” They say.
The issue I have with this approach is that I believe inside every Candy Land developer there’s an awesome developer just waiting to burst out.
And if that developer chooses to give in to their fears and take the easy way out of not deciding anything, the world is just a little worse off.
So what could drive someone to become a Candy Land developer?
I came up with 4 reasons. A combination of which could explain why a developer would decide to regularly avoid making a decision:
- They don’t care enough about their current job to make meaningful decisions.
- They don’t want the responsibility that comes with making a decision.
- They don’t think they’re qualified enough to make a decision.
- It’s easy for them to let others make all the decisions.
If you’re going through life thinking any of the above are true, you’re not living your full potential.
- Caring about the product you’re developing and the technology you’re using will significantly increase your joy from coding. Do it for yourself. If you can’t at your current job maybe it’s time to consider looking for a new opportunity.
- Taking responsibility is scary, but worth it. When you take responsibility people feel like they can depend on you. They will appreciate you for it.
- Sometimes you’ll think you’re not qualified to make a decision. You’ll still benefit greatly by going through the mental exercise of thinking “What would I do in their shoes?” You can then go to your team leader or CTO with a suggestion on what you think is right instead saying “Tell me what to do”. You’ll learn more this way, and they’ll appreciate you for it.
- Taking the easy way out is bad for one simple reason. By doing so, you’re not fulfilling your true potential. Which means you’ll be denying the rest of the world of what you have to offer.
But even after taking into account all of the above, I still think there’s more this issue.
There’s more to why being a Candy Land developer is such a bad idea.
The Power of Habit
It might be possible to find a well informed, passionate JavaScript developer who’s also a Candy Land developer.
But I have yet to meet such a beast. And I think I know the reason for that.
You see, giving up on joining discussions and standing on the sidelines is a keystone habit.
In the best selling book, The Power of Habit, a keystone habit is defined as a habit that naturally leads to other habits and behaviors.
Let’s take exercising for example.
People who exercise also tend to eat healthier. Which in turn leads to a feeling of wellness and higher self esteem. Which in turn leads to other positive things.
Exercising is a keystone habit.
When you avoid making decisions and choose to constantly stay on the sidelines, you’re creative a negative keystone habit.
The Habit of being a Hands On JavaScript Developer
Now let’s say your team is debating whether choose Ember or React for your next team project. You have two options, either actively participate and help reach a consensus or sit this one out and say “You’re fine with whatever the team decides.”
If you choose to take part in the discussion, it will inevitably lead to you educating yourself with one or two of the frameworks before reaching a decision. You might even explore other alternatives such as only using Babel for ES2015+ support and developing the rest in-house.
Whatever the decision may be at the end, I’m sure you’ll end up more educated by the time the discussion is over.
If you choose to let others decide however, you won’t have any incentive to research those frameworks.
Sure, you’ll eventually have to learn the framework your team decided on. But you probably won’t bother with learning the key strengths and weaknesses of that framework. Or perform an analysis of all the features framework has to offer.
A key learning opportunity will be missed
When you multiply this one event by the significant number of choices developers have to make every week, every month and every year, it will add up.
A Candy Land Developer will naturally avoid learning new things and deepening their knowledge.
Blue Pill or Red Pill?
It’s up to whether choose to pretend you’re playing Candy Land. All of the cards have been stacked in advance, and the game is already won or lost.
Or you can choose the other path and take a stand. Decide where you think your project/product/team should go. Discuss it with others, learn and evolve.
At the end of the day, the choice is yours.