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.
Take the case of Javascript. In the mid ’00s, Javascript was the go-to accessory to enhance your website (namely by adding web-based animation). During the past five years, Javascript grew up and now presents a mature ecosystem, capable of handling large scale web applications without any dependencies.
As the all-Javascript development grew in popularity, developers lunged to get on board. Teams tasked with adopting the JS workflow had to learn both the basics and an array of other tools. Since the JS community is mainly open-source, independent developers were building tools and libraries that eased and enhanced the configuration and build processes within the JS ecosystem.
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.
Enter a phenomenon called “Javascript fatigue.” With every library mastered, a competitor library would appear. Or it turned out a library needed two other companion libraries to work properly. Developers were often left second-guessing themselves and their choices. “Is my front-end workflow using the best task manager? Should I change it mid-stream?” “I’m using Angular, but the community is touting React? Do I need to start my half-built project from scratch?” “Does this replace jQuery?”
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.
I don’t intend to downplay the exciting growth of Javascript but to highlight the dysfunction that can occur if the introduction of new technology isn’t orchestrated with some sort of process. Here are three conventions that our team uses to help us benefit from technology advancements without becoming overwhelmed by them:
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:
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.
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.
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.
In summary, your choice of web development tools — from PDF generators to marketing automation to CSS preprocessors to Javascript frameworks — affects the entire project staff: both developers and account management. Tools are made to assist. If they become paramount, your product and process (and team) could suffer.
Good luck on your next project!
"*" indicates required fields
