Taking a Balanced Approach to New Technology

In the tech world, using "new" as a prefix can evoke a certain burdensome connotation. New technology, new language, new framework, new phone, new feature, etc. It feels like there's something new every day, as though one could spend their entire life reading about new technology, leaving no time to actually use the technology. In other words, the tech world is in a constant state of disruption.

Look at JavaScript frameworks. It seems like there's a new one every day. First we were all talking about AngularJS, which became just Angular, then React quickly became the talk of the town, and now Vue is what everyone is talking about. And there was some short-lived fame for other frameworks like Ember and Meteor.

Or take a look at static site generators. For years I worked exclusively with Middleman and Jekyll. But with the explosion of the Jamstack, thanks to players like Netlify, SSGs have experienced a resurgence and now there are several new players on the scene, including Hugo, Gatsby, Next, Hexo, and many more.

How can you possibly take the time to know which tools are best for your project? When is the appropriate time to jump into a new language or framework? When is it time to start using a tool and how do you know which tool to use?

When answering questions like this, I tend to drift toward a balanced approach. I believe balance belongs in everything you do, and I use practices like checking in with myself to make sure I (and what I'm doing) remains in balance.

I use the same approach for new technology, whether it's a new hosting platform, operating system, or JavaScript framework. It looks something like this:

When the tool is brand new, I pay attention to its development and what developers are saying about it. But I stay patient and wait for the honeymoon period to end to see if there's more to it in the community than its novelty. If the positive talks remain, I try it—I create a proof for concept containing types of features I might use in a production-ready product. I want to get a sense of how well the tool can solve problems I face on projects I get paid to work. Based on the outcome of that POC, I either consider selling the tool it into my next project, or I move along until and unless something urges me to go through the process again.

To say it more prescriptively:

• Don't bring a new tool into a production application when you've never worked with it.
• Try the new thing within a proof of concept once you believe it's going to stick around.
• Use the tool in a production-ready application when you're happy with how it works and confident in its community, support, and future.

Over the last two years, I've built proofs of concepts using several tools that were new to me at the time. While the list is much longer than what I have below, the following tools are those you are more likely to recognize:

• Jekyll
• Hugo
• Gatsby
• Angular
• React
• Vue
• Contentful
• Dato
• Netlify

Since building my proof of concepts, I've used about half of these in production applications. But now I know (generally) what it's like to work with all of them. That means I am not equipped with more tools in my toolbox, along with the ability to make a more informed decision on which one(s) I should use for my next project.

Avoid being be too late to the game. But don't get too far into a bind from which you can't escape. Stick yourself right in the middle—stay balanced—and you'll be a knowledgeable and profitable developer.