"New" is a dangerous word in the tech world. With so much changing every day, how do we make sure we know which tools and technologies to invest our time in and which ones to leave behind?
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.
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.
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:
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:
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.
A handyman (or handywoman) has a toolbox full of tools for any job that comes their way. What should be in your toolbox? And when should you open it?
Balance is the key to doing anything well for a long period of time. But balance can fade slowly over time. We must check in to ensure we are maintaining balance in our lives.
If you want to do something well in life, you must do it with balance.