“Developer fatigue” is becoming a real problem. Well-regarded analysts and developers (including Stephen O’Grady, Tim Bray, Ed Finkler, Marco Arment, and Matt Gemmell) are talking about the increasing frustration experienced by many developers who feel obligated to keep current with the constant and increasing flood of new languages, libraries, frameworks, platforms, and programming models that are garnering popular attention in the developer community. While there’s nothing wrong with trying to stay up to date with the latest technology, there are a number of downsides that can work against developers:

• The need to learn the latest technology can take away from time actually being productive with familiar tools.
• Many new technologies are still half baked and have inferior tooling, costing extra time and effort to actually get them to work, and to track down and fix subsequent problems.
• The exploding pace of introduction has reduced the half-life of each new technology, decreasing the value to any new skills acquired.
• As the half-life of each new technology decreases and it’s supplanted by the latest new thing, technologies don’t have time to grow and mature.
• As more and more software technologies become available for use, the risk of making bad bets on new technologies increases.

Tim Bray memorably expresses the frustration of the “discouraged developer”:

But there is a real cost to this continuous widening of the base of knowledge a developer has to have to remain relevant. One of today’s buzzwords is “full-stack developer”. Which sounds good, but there’s a little guy in the back of my mind screaming “You mean I have to know Gradle internals and ListView failure modes and NSManagedObject quirks and Ember containers and the Actor model and what interface{} means in Go and Docker support variation in Cloud providers? Color me suspicious.

While this problem has been around since the dawn of computers, and developers have been complaining about it for just as long, it’s getting much worse, for a number of reasons. There is the increasing push for “full-stack developers,” as Tim Bray mentions above. Part of this is a desire to “do more with less,” since a single developer is now expected to do what a team of specialized developers once did, and part is a belief that a full-stack developer is more talented or productive than a more specialized developer. However, the pressures of becoming a full-stack developer, or maintaining that status, often lead to developer fatigue, due to the effort necessary to stay up to date at all levels in the stack.

There are a number of other reasons for developer fatigue. The rise of open source has broadened the software development field and allowed many new projects to be introduced to the development community. The Internet has made it easier to disseminate projects to the broader community. A proliferation of new hardware, including mobile, wearables, and the Internet itself, has created opportunities for new software technologies to run on those platforms. And finally, software companies are facing pressure to introduce new technologies in order to stay ahead of, and distinguish themselves from, their competitors.

How can a developer possibly keep up with the latest big thing while continuing to stay productive? Professional development is important, and nobody would suggest ignoring new developments. Perhaps the best way to keep up is to take it slowly; integrating features of new technologies into your projects as you need them.  In my experience, actual need to use a technology is the best reason to start learning about that technology, and the best way to retain the skills once learned. The alternative, jumping in and learning a new technology for its own sake, an approach often referred to as “warehousing,” is quite popular, but is much less effective.

By introducing yourself to new technologies gradually, focusing on those aspects that can help you solve problems immediately at hand, you can stay productive using familiar technologies and tools, and introduce the new stuff one feature at a time. It may not be possible to do this in all cases, but if your familiar platform is .NET or Java, you’re in luck. Many new languages, platforms, and other software technologies have a version that’s implemented in .NET or Java (some are available in both). If both the familiar and the new technologies are implemented on the same platform (that is, both on Java, or both on .NET), integration should be straightforward, and is probably already designed into the new technology. In other cases, where the new technology is .NET-based, and your regular technology is Java-based, or vice versa (or, where you need to use both .NET and Java with the new technology), JNBridgePro can help.

In the last couple of years, we’ve produced numerous examples showing how a familiar “legacy” technology like .NET or Java can be integrated with a new (or at least relatively recent) technology like Hadoop, Groovy, or Python. In the coming year we plan to continue to show how JNBridge products can work with emerging technologies including microservices containers, functional languages, cloud technologies, and NoSQL databases. In our examples, we’ll be focusing on how you can bring in new technologies at your own pace, without having to assimilate the entirety of a new language, API, or platform. Our goal will be to show how developer fatigue can be avoided, while still providing the opportunity to keep current on the ever-increasing number of new technologies being introduced.

Are you suffering from developer fatigue?  Which emerging technologies would you like to see us address?  Drop us a line and let us know.