by
on March 31, 2014

I’m starting to wonder if the front-end development community has begun to turn a corner. Lately, I’ve seen what could be described as a backlash against the ever lengthening list of tools, frameworks and libraries. There seems to be a growing consensus around the idea that something needs to change, though, admittedly, without a clear picture of how to change it.

Trying to change it, though, smells a bit like stifling innovation – which we certainly don’t want to do. I always tell my kids that you can’t control what other people do, you can only control how you react to it. So, along those lines, perhaps the answer isn’t so much changing the behavior of the community but rather how we respond to those behaviors. In this article, I want to discuss some ideas for overcoming the “paradox of choice” in front-end development.

Something Changed

This is a topic I’ve hit on myself for a while. When I first refocused on front-end web development using HTML, CSS and JavaScript close to 3 years ago after spending a few years in the world of Flash and Flex, I was initially overwhelmed at the number of framework options. Looking back, that list was laughably small compared to what it is today. I even touched on this last year in a session for Ignite at the O’Reilly Fluent conference and then again last September for an article on this site. The message seemed to resonate but I also didn’t get the sense that people thought it was as deep an issue as I did.

Things seem to have changed. For example, you have leaders within the community such as Rey Bango speaking about The Learning Conundrum and the costs both personally and professionally of trying to stay on the “hamster wheel” of new tools. Louis Lazaris, who, perhaps not coincidentally, runs Web Tools Weekly, said that we are “drowning in tools in the web development industry.” Jeffrey Way wondered “why do we continue learning new techniques, if those same techniques will invariably become out-dated within a couple years or so?” Addy Osmani wrote about “front end choice paralysis.” As a commenter on Facebook asked when I recently posted about a new tool, “isn’t it too much?”

Sometimes this feedback comes in response to some new library being released. For instance, there was a lot of negative blowback over some of the recent build tools for JavaScript. While this reaction is understandable, it also could have the side effect of stifling legitimate and worthwhile innovation. What if the tool we’ve all been waiting for simply doesn’t get made or never gets publicly released because it’s author fears getting flamed over creating yet another framework.

Filter Out the Noise

One of the biggest difficulties front-end developers face can be deciding what is worth paying attention to and what isn’t. If you follow social media, Hacker News, EchoJS or even a handful of blogs, it can be hard to decipher the tools or frameworks that are deserving of investigation versus those that maybe just aren’t there yet. Fortunately, there are a lot of people out there in the community that are doing the work of helping you filter this down.

There are no shortage of roundups and newsletters that you can rely upon to at least get the list to something manageable. Many of these also have a specific focus so that you can even choose only the ones most relevant to you. Some even focus on a particular framework or tool, which can further filter your reading list. Here is a by-no-means-complete list of the ones I am aware of grouped, as best I can, by their primary focus:

Web Design Focused

Collective by CoDrops
CSS Weekly
Web Design Weekly
Responsive Design Weekly
The Sass Way
Sass News

Web Development Focused

My suggestion, only subscribe to the ones that will be particularly relevant to you. You don’t want to replace one batch of noise for another. Also, learn to skim them and pick out the things that stick out as either potentially important to your work or something you find personally interesting. That is an important distinction to make, which leads me to my next suggestion.

Distinguish Between Useful for Work vs. Fun for Experimentation

If you do a good job of distinguishing those projects that are actually worth investigating for your job versus those that just seem potentially cool and fun to play with, you can whittle down the list of what you need to focus on.

Of course, what is suitable for your job is dependent on the type of job you have. For example, a consultant may have a longer list of tools or frameworks to learn while an enterprise developer may only be allowed to use projects that have been formally approved. There’s obviously a wide spectrum in between.

The point here is that even though something looks new and interesting doesn’t mean it is worth investigating deeply for work purposes. I’d suggest sticking only to those tools and projects that have an established community, proven track record and, potentially, some availability of support when choosing something to use for work. Right there, that eliminates an enormous amount of noise.

But that what about all the cool tools, libraries and frameworks? When do you get to have some fun?

Remember What You Love About Programming – Experiment

Being a developer is a job of choice. I don’t think I have ever met anyone who became a developer out of a lack of other options – they did it because they love to design or code. Nonetheless, I often hear things along the lines of “work doesn’t give me time to experiment and learn.” The question I have is, since when does work dictate what you can do outside the office?

We all lead busy lives. However, I bet you became a developer because you enjoyed it. But somewhere along the line everything related to development got lumped into the “work” bucket. This meant that if it didn’t happen at the office, it won’t happen. Coding for fun became a thing of the past.

Even if work doesn’t give you experimentation time, it is important that you find the time to experiment. It may benefit your career and will definitely will help you remember what was fun about being a developer.

Setting Goals for Experimentation

Even once you’re determined to find time for experimentation whether it is at work or outside work, one of the toughest things to do is to come up with an end goal for your experiment. Personally, I find that setting large goals like building a complete web application or mobile app can make the whole process seem daunting. I always find that setting a smaller but achievable goal works better.

I generally start by adding a tool or library I find potentially interesting to look at for fun to a bookmarks folder (I call mine, “potential topics”). Once you’ve identified what you want to try, the next step is to set a goal and a deadline. Here are some things you can do:

• Speak:
  • Agree to present the tool to a user group;
  • Set a “brown bag” presentation to share with your colleagues;
  • Submit a topic about the tool to a relevant conference.
• Write:
  • Write a tutorial on your own blog;
  • Contribute an article to a site (like this one!);
  • Contribute to the tool or framework’s documentation.

Any one of these things will not only give you the opportunity to experiment with a goal and deadline, but will be the kind of thing that can help build your reputation in the community and improve your resume.

Avoid Being Overwhelmed

I think if we can filter out the noise, determine what’s worth investigating for work versus experimentation and, finally, find time and set goals for experimentation, it can be much easier to avoid feeling overwhelmed by the flow of new tools, libraries and frameworks. We can change a reaction of anger and frustration into a positive and fun opportunity to find things worth learning and having fun doing so – all while boosting our resume.

I’d love to hear people’s thoughts or other strategies. Feel free to share in the comments.

Brian Rinaldi

Brian Rinaldi is the founder of Flippin’ Awesome. Brian works as the Developer Content Manager at Telerik (though this site is not affiliated with his employer) focused on ensuring that the Developer Relations team creates top notch content for the web development community. Previously, Brian focused on publishing HTML, CSS and JavaScript developer content for the Adobe Developer Connection at Adobe.

Brian has published in a variety of technical publications over the years, has presented at numerous conferences and events and has served as a technical editor on a number of books.

You can read Brian’s blog archive with 9+ years of content at remotesynthesis.com (he still posts, infrequently). You can find a full list of Brian’s past publications and presentations. Follow Brian on Twitter @remotesynth.