What I Learned from Working in Failed Platforms

Recently, Adobe announced the end of Flash (sort of) as well as the end of their Edge tools and services. This marked a milestone of sorts for me - the end of a number of products that played important roles in my career (for instance, I was the Flash Community Manager at Adobe around the time of the infamous Steve Jobs letter).

It also seemed like a good opportunity to discuss the often hard earned lessons these experiences taught me about the most important skill a developer can have to thrive in this industry - adaptability. In this article, I want to share a little of the experience of a career littered with failed technologies and the lessons gained through these experiences.

As developers, we're a passionate bunch. I'd say that, as a group, we can be much more intense about our work than the average person. This passion is part of what makes the developer community so exciting, but it also can lead to a belief that my platform is the best platform. Maybe it's part of doing a job where every problem has a thousand possible solutions that makes us so certain, sometimes, of the particular solution we chose.

We're often so tied to our particular platforms or solutions that we even add them to our title. I'm not just a developer, I'm a web developer, a Java developer, a .NET developer, an iOS developer, etc. Sometimes, we're so certain that we're even willing to narrow that down to a particular tool on a particular platform. I've often heard people refer to themselves as a Rails developer or an Angular developer, for instance.

But what happens when this all goes south and the technology (or technologies) that you've tied your career to, your title to, and perhaps even part of your identity to, suddenly becomes inviable?

It Can't Happen to Me

In the here and now, it can be hard to imagine your beloved languages, platforms or frameworks becoming irrelevant or completely going away. But we work in a fast changing industry and my own personal experience has proven that things can, sometimes, change literally overnight. Before I get to the lessons, let me share some of my story.

I started as a hobbyist developer back around 1996.

First I started toying with basic web development with HTML and then a little bit of Flash (which didn't even have variables at the time). Eventually, I decided that I wanted to do this for a living. I had a friend who convinced me to take a Fast Track to ColdFusion course - ColdFusion was hot back then. This led to the first of many full-time positions as a ColdFusion developer at companies as well known as Hasbro and Sun Life Financial.

I loved ColdFusion and the ColdFusion community (the latter I still do). I spoke at conferences about ColdFusion. Wrote articles about ColdFusion. Even ran the ColdFusion User Group in Boston.

I was, truly, a ColdFusion developer - meaning, my entire career depended on the success or failure of ColdFusion.

The thing is, ColdFusion was not a growing community. From the days at Macromedia and then at Adobe, it was constantly hampered by rumors that it was being eliminated - though, in fact, new versions are still being released to this day.

Tired of fighting about ColdFusion's future and whether it was still relevant or not, I decided to move much of my effort to Flash and Flex. You may laugh today but in 2006, Flash had a strong, growing and vibrant community, and Flex was leading the long list of "rich internet application" solutions like Silverlight and JavaFX.

Just as I had been on ColdFusion, I was "all in" on Flash and Flex (and eventually AIR), writing, speaking and even founding a conference in Boston focused on the technologies. These efforts eventually led to my being hired by Adobe as a Flash and Flex Community Manager in 2010 - yes, when Steve Jobs posted his famous (or infamous) Thoughts on Flash.

While the atmosphere in the community and at Adobe was intense, nothing changed immediately. The Flash community was still active and strong. Companies were not yet ready to abandon Flash entirely, and Flash on Android seemed like it might actually become viable option.

Then, one day, this happened.

Well, not literally. But there was a massive reorg. Mobile Flash was dead. Flash itself was now focused on gaming and video exclusively. Flex was no longer being developed. Adobe was investing heavily in web standards. And my team was almost completely eliminated.

I went from one day focused on Flash and Flex to the very next day, on a different team, focused on very different technologies.

Sadly, in my short (ok, not that short) career, the list of technologies that have come and gone is long. Flash, Flex, AIR are gone. ColdFusion survives but seems to be fading further. All their related frameworks (Fusebox, Mach II, Cairngorm, RobotLegs, etc.) gone... Did I mention I worked in Director and Lingo early on? Let's forget about that.

Sometimes it feels as though I was deeply involved in every failed technology during the past 20 years. But the experience taught me some valuable lessons - lessons that I often feel many developers today have not yet had the opportunity to learn. At the risk of sounding like a crotchety old man, I'd like to share them.

Lesson #1 - Be Open-Minded

Articles or attend sessions that pit technologies against each other can be fun - why React is better than Angular; why Ruby is better than Python, etc. But it's important to keep them good natured. This means that, even as you advocate for your preferred platform/language/technology, you also keep a healthy skepticism about it.

In other words, the other options don't "suck" and other people aren't "stupid" for using them. It means that you understand that every developer and organization has a different speed at which they are comfortable adopting new technologies - and no one is an "idiot" for being a couple versions behind or for not updating to the latest, hot framework.

Being open minded, means being civilized in our discussion of technologies, knowing full well that our preferred choice now could be a dead choice in the future. This is important because the very people you disagree with today may be your colleagues tomorrow.

When the Flash changes came (i.e. around the time of the reorg), the community effectively split into three groups: 1) those who were prepared to move on to web standards and did so quickly; 2) those who were taken by surprise but gradually, if somewhat reluctantly, made the transition and 3) those who were angry and refused or fought the transition. I can practically guarantee that the first two groups fared better in the long run - in fact, many of them became leaders in the JavaScript community (including my colleague Cody Lindley), bringing some of the unique expertise that the Flash community had in the areas of animation and interactivity to the JavaScript community.

Lesson #2 - Try New Things

Quite frequently, we fall into a choice and then rationalize that it is the "best" option after the fact. Then, once we become deeply immersed in a particular solution - once it has become, for better or worse, part of our identity as a developer - it can be hard to see its shortcomings or the benefits that alternatives may offer. This can make us myopic and put us at risk if the day comes that our "best" option is no longer a viable option.

Despite what some job postings might imply, you don't need to be an expert in everything, but you should at least venture into new territory from time to time. For example, create a small, fun side project in a language you don't know. Or try working through the getting started guide of a framework that you've been hearing a lot about. Or take a video course about a tool that you've never used before.

The goal isn't to change your mind or move in a new direction, but to keep you aware of how the landscape around you may be changing.

Trying new things can also prevent us from getting overly dogmatic about our choices, which can help lead to a successful career. For instance, I have spoken at one of the main ColdFusion conferences, cf.Objective(), which is now dev.Objective(), over the years, even long after I'd basically stopped doing ColdFusion. Many of the speakers and even the attendees at that conference in recent years were ColdFusion developers who had found great success in areas outside ColdFusion development. Their willingness to try new things opened the opportunities for this success, while still allowing them to maintain the ties to a language and community that they still have a strong affinity for.

Lesson #3 - Don't Paint Yourself Into a Corner

The most important lesson I've learned is to not let your career and your identity become too tied to a single technology. I used to believe the depth of my knowledge about a single tool/language was a competitive advantage. Today, I think that, while depth of knowledge about a single tool/language has its merits, these can be more than offset by how much it limits your options.

Nowadays, I often jokingly refer to myself as the Frog Pond, a popular splash pool in Boston Common - I cover a lot of ground but am not very deep in any one area. I rely upon my ability to learn more about whatever I need to know rather than rely upon my encyclopedic knowledge of one topic. This gives me the confidence that I can adapt however I need to in the future - just as I've been forced to in the past.

Put it this way, you want to be able to go wherever the best options are available, regardless of the technology. Today, everything seems to be moving to JavaScript - the front-end, the back-end, mobile development, desktop development, IoT...and the momentum may seem unstoppable.

But, even as it may seem hard to believe today, there was a time when Java seemed equally unstoppable. I thought that I'd have to learn Java if I ever wanted to have a decent job down the line. Fast forward to today and, while there are still plenty of Java jobs, I think that it's safe to say that few people are arguing that Java is the future.

More importantly, by not painting yourself into a corner, you also give yourself the option to not follow the trends. There are needs for a lot of different types of developers and, if you're open minded, willing to try new things and not painted into a corner technology-wise, you'll be best prepared for whatever opportunities might come your way.

Epilogue

At this point, I shared much of my career history with you. Obviously you know that I ended up at Telerik, but I just wanted to add how I think this fits into the overall picture I've painted here.

One of the things that I loved about Telerik when I was first introduced to the company was that it's products were not prescriptive. Sure, they were most known for .Net, but if you want to use Kendo UI with Java or PHP, that's fine. If you want to built mobile apps on the Telerik Platform with Angular, that's fine, but if you prefer something else, that's fine too.

The lessons I learned from my work in failed platforms was part of what drove me to Telerik because, in my opinion, Telerik's tools and platforms are what I believe every developer should be - adaptable.