A pleasant flurry of new technology can quickly become an overwhelming avalanche if you’re trying to keep up with every software snowflake that arrives. Developers are required to learn and scrutinize new technologies almost daily — it’s central to the very job — but there are good and bad ways to go about it.
The problem was, with such exponential community growth, a dozen libraries spawned a dozen more. Some did one thing well, some promised to do “all the things,” some aimed to be the “industry standard.” The ones that had the best marketing — and the leanest, although sometimes incomplete, documentation — usually won the temporary popular vote.
This “fatigue” meant more working hours were spent configuring libraries rather than building things with them. The allure of a new technology overrode focus on the end goal.
1. ABC: Always Be Collecting
As was the case with JS fatigue, it’s easy to be paralyzed by all the options, but you can’t dodge the need to learn multiple new technologies. By collecting, you’re not spending hours mastering any given technology. Instead, you’re scanning any potentially helpful tools that are gaining in popularity, asking honest questions about each and archiving if truly important. The goal is to have a low-commitment awareness of potential tools without it turning into a sprawling mess of links.
Basic questions could be:
- What does it do? Do we need something that does that?
- What technology does it use?
- Is it open-source or paid?
- Is it relevant to our product offerings? Can it introduce a new offering?
As your collection builds, you can always revisit an item if you need to deep-dive, either during downtime or if a real need arises.
2. The Solution Should Serve the Product
This is a simple one: Be honest about what you’re building. If you have a large website on a tight deadline and you’re already versed in WordPress, use it. If you’re working on a smaller website or a small web app and have some flexibility, consider taking a deeper look at a JS framework, like React or Angular (or something sourced from your growing collection).
If you’re upwards of 10 hours into learning and you’ve yet to find a suitable reason for bringing your finds to a real-life product, it might be appropriate to curb the research for now.
3. Everything Costs
In addition to knowing the options, consider the cost. In fact, this should be high on the list of collection questions. If you embark on learning a new technology, even open-source, your currency is the time spent on that. Keep your end goal in mind. Hours spent researching without real-life payoff could be a misdirected waste — exponentially compounded if multiple team members are researching.
On the flip side, if you pay for an enterprise solution, you’ll no doubt have a lot at your disposal, but you’ll be paying a tidy penny for ongoing support, training and add-ons — all under proprietary binding of the manufacturer.
Though paid solutions seem higher risk, both situations can affect the bottom line for your company or client.
Good luck on your next project!