If you are like me, you subscribe to a dozen good publications that regularly churn out articles on the cutting edge of design, code and user experience. It becomes hard to keep track of all the good ideas and much worse, incorporate all of those ideas into your workflow.

A new layout system, a new way of performing discovery with clients, a new prototyping tool…it’s hard to keep up. My way of dealing with the madness that is the web is two fold.

Firstly, never jump on fad trains. Wait for the dust to settle and then pick the one that works best for you. A lot of open source projects and tools for the web are products from giant internet companies. Polymer and React instantly come to mind. With giant companies come giant budgets for marketing, a great stage for launch in their yearly conferences.

These projects, hence, get a great buzz going around them during launch time. The demos on stage look spectacular and make web development so easy. To really understand how any of these tools work, you need to let the dust settle down.

This comes with the compromise of not being able to play with latest tool in the market. The flip side is creating risky projects, lack of answers on stack overflow and waiting for features to be fleshed out. Not to mention constant change as the project evolves from beta to v 1.0.

Of course, there are some exceptions to this rule. If you really find a project that speaks to you or is built around your specific way, then I’d go right ahead and jump on it. Otherwise I choose to be a dark matter developer.

The second way I deal with the madness of the web and trying to play catch up is the rule of one – one new technique / tool / framework per project. This works really well for me because I have a personality type that gets excited when beginning new projects. There is an excitement and a lot of learning from past projects that can help shape this new project in bette ways. Solve problems faster, reuse some code (or atleast the way you code) and newer tools.

When you are learning only one new thing, you eliminate the possibility of burnout. Take react for example. In order to get the best out of react, you need to also learn redux and use webpack. Those are entirely new ways of thinking about several different parts of the workflow. Not only is the learning curve high, you are also losing out on productivity. I tried this at one project this year and it was tough to get even the most basic things done.

The other advantage to this approach is prioritization. You could be excited about several things but you are forcing yourself to consider one. You make informed choices based on where this new tool / project is in it’s life cycle and which part of your dev flow requires change more urgently.

Though it sounds simple in theory, sometimes it’s difficult to execute. For one, there might be several pieces to a new tool. If you are moving from grunt to gulp, for example, requires a lot of rework. It involves changing, figuring out which of the plugins among thousands is the right one for you, or which router to use.

This is where the first rule comes to help. By waiting long enough to have answers to some of the basic questions, it helps to weed out the blotched attempts and focus on producing code, releasing software – all while learning something new.

Another thing to consider while trying something new is “how easy is it to replace this?”. I picked this idea from CSS-tricks. Let’s say you try angular JS out but you feel like it’s not the right framework for you. Is it easy to swap it out and use a different framework instead? When using less / sass, this is a great thing to consider. It doesn’t matter which one you use, because it all compiles down to CSS. And should you choose to move over, your CSS is intact. Very low impact if you ended up choosing the wrong project.

In conclusion, I’d like to leave you with three questions I ask myself before taking on something new.

1. How long has this project / tool / framework been around? Try to see how active the development is, what kind of issues are on github, and most recent stack overflow questions. If you get a vibe that the conversation has gone beyond the basics of how do I do X to more nuanced discussions, the project is in the right phase to pick up.
2. What is the learning curve? What’s the general consensus on how hard or easy is this thing? Are we talking a few hours or a few days? What’s the effort involved? Mind you, this differs on a case to case and person to person basis.
3. How easy is it to replace?