A boundless and growing variety of tools comes as little surprise to active developers. It's not uncommon for me to discover a few new frameworks a day, and read about several popular library updates each week. The same holds true for authors, artists, musicians, and other creatives. No matter what profession we select, there's an enormous increase in the availability and variety of tools at our disposal.
The major concerns for professionals is tool quality and stability. Will a given framework or platform pay off dividends for the time spent learning, maintaining, and mastering it? We all play the role of investor when it comes to choosing technology worth learning, and there's never a wasted surplus of free time.
One mistake I keep repeating is struggling to maintain multiple small applications at the bleeding edge of a few attractive development stacks. It's challenging to be aware of what's in the latest release of Rails, NoSQL soup, or JavaScript's framework of the day. That list doesn't even consider the depth of domain specific utilities such as datamining or visualization.
Each programming language hosts thousands of utility libraries of which only a rare few grow into self sustaining communities or stable elements. Out of those "survivors", only a handful are applicable to the type of work you're doing right now.
Build ahead or behind the bleeding edge
There are two sure fire methods to hedge one's bets on technology. Either build your own tools, or select proven tools based on historical quality and reliability.
The advantage of building tools yourself is having full control of updates and release cycles. There's no driving force to jump to the latest and greatest because you dictate when new versions are ready for your products. The code is as reliable as your code review guidelines. In open source development there may be forks and community updates which are attractive, but there's still no requirement to jump to a bleeding edge. Your team can maintain productivity and let evolution take its course, adopting attractive features when they're both stable and broadly endorsed. In fact your team can experiment in community branches, and fold them into production when it best suits product, customer and market needs.
The other way to stay clear of edge effects is to choose stable and mature tools. There's a good chance that c++ compilers, and java virtual machines will be around for some time to come. Embracing utilities which rely on these foundations is a safe bet.
In my professional experience I've been on both sides of the bleeding edge, by creating my own utilities, and adopting proven standards. Each path has its own merits and drawbacks, so take time deciding which strategy is right for your current project and task. Your clients and team will appreciate your careful thought and review.
While exploring a novel tool is almost never a waste of time, we are judged predominantly by our ability to produce, not our ability to learn. Part of team leadership is making objective choices, which aren't always popular.