Bradley Braithwaite
1 import {
2 Learning,
3 JavaScript,
4 AngularJS
5 } from ''
6 |

The Future of Technology X

Thoughts on career and technology planning.

on musings, learning

The future of technology

The golden age of the Microsoft developer ecosystem is behind us and so could be your career is the opening paragraph from a post I read recently, titled the collapse of the .net ecosystem. I usually take such posts with a grain of salt, as I’ve read many along the format of Leaving .Net, followed by a list of reasons as to why .Net is so terrible and why Ruby/Python/Whatever is so much better. Such posts are not just restricted to .Net e.g. Don’t use AngularJS and Farewell Node.js. This post was a little different, since the author took steps to quantify and present a hypothesis based on data, as opposed to a list of personal grievances about a specific technology. The post goes on to state that there’s an undeniable downward trend shown across all data sources we’ve reviewed: The .net ecosystem boomed in 2010 and lost approximately 40%-60% of adoption since then. The author concludes that .Net developers should strongly consider moving to another technology stack.

This is not a follow up post to speculate about the future of .Net, but to share my thoughts on the future of any technology in relation to my career. Think of this as being advice I would give to my younger self.

In relation to the story I opened with, what should .Net developers do (I spent many years working with .Net technologies, by the way)? Learn Java? Python? What if those technologies drop in usage once you’ve reached proficiency? How do we best prepare ourselves to not get caught out by the collapse of an ecosystem? The obvious answer would be: don’t wait for it to collapse, but it’s more nuanced than that. Just because a particular technology loses market share doesn’t spell disaster, the missing statistic is, based on your regional area, how much competition are you faced with?

Don’t be Motivated by Fear

The following quote from Andrew Grove (the co-founder of Intel) is often found lurking in the comments section of posts that discuss the future of a given technology: only the paranoid survive.

I think it’s a good strategy to seek out statistics and look for technological trends, but less so out of paranoia. The post I referenced emanated fear, using words in the headline and section headings such as collapse, sinking and plummeting. I understand this mindset, we’ve spent years grafting to build experience and career capital with a specific technology, and then it’s taken away from us and we’re back to square one. Just ask the Silverlight developers! We’re also subject to how 90% of IT recruitment works, where must have 5 years of technology X is the common method of filtering candidates, adding extra paranoia as to where we should spend those 5 years. It’s important to consider the future, but I don’t think it should be from the perspective of fear, what-ifs, and reacting to negative (perceived or factual) trends.

If fear shouldn’t motivate us, what should? Rather than looking over my shoulder so that I don’t end up being a specialist in a technology that nobody is hiring for, I try to regularly review what I can offer the world in order to compete for the opportunities I find interesting.

What Makes you so Special?

The Start-Up of You written by Reid Hoffman (co-founder of LinkedIn) has some great ideas that resonate with me, in particular the idea that as professionals we are always in Permanent Beta; we’re a work in progress that constantly needs to evolve. A building block for the framework of the book is being able to answer the following question:

A company hires me over other professionals because…?

The book then goes on to ask: How are you first, only, faster, better or cheaper than other people who want to do what you’re doing in the world? What are you offering that’s both rare and valuable? If you list yourself as just a Technology X Developer, then you are highly dependant on that technology and more likely to be caught up in the type of downward trend described in the opening paragraph of this post. Unless of course, you are the first, only, or have some distinguishing features for Technology X that sets you apart from the crowd.

I like to think of it as adding AND to your response to the initial question. Expert with Technology X AND Technology X Book Author AND Holder of Community Award from creators of Technology X. No ANDs and you may be restricting yourself; too many ANDs may be diluting your offering. At the time of writing, here’s mine: JavaScript & AngularJS Expert AND Web Expert, experienced with large-scale system architecture AND Technical Author AND Condescending Blog Post Writer. A few years ago, this would have started with C# and .Net Expert, but the rest is the same. Working on huge systems has been great for my career, as regardless of the technology used, the problems faced when working with such systems are similar.

As an exaggerated example of a distinguishing feature, I don’t think that Jon Skeet would have any problem getting a C# role. Even in the face of market saturation. Even if C# were to go out of fashion there will be complex legacy systems screaming for his help. But what about the rest of us? We could stand-out by being cheaper to hire? But that’s probably not what we want! A more realistic example is to be skilled in Technology X AND have expert knowledge for a chosen domain. A person with this skill combination is less at risk if Technology X is superseded by Technology Y since they still have the domain expertise. If you choose to be the type of developer/consultant who jumps straight onto the new Technology Y, then changing trends is an occupational hazard that you face, but if you’re moving quickly enough, you’re likely to be there first.

Avoid Competition

Peter Thiel’s book Zero to One has a running theme of avoiding competition. If, as do I, you think of your professional career akin to being a business, his book advises to avoid competition as much as possible. This can be difficult to achieve with programming languages, since competition is inevitable with any mainstream language such as C#, Java, Python, JavaScript et al, but in combination with other factors, such as domain knowledge, development methodologies, specific commercial experience etc it’s possible to create a unique offering that limits competition. You will often hear business advice about creating a niche, this is what they mean.

A great quote that encapsulates the philosophy of the book is that:

The most contrarian thing of all is not to oppose the crowd but to think for yourself.

If enough people start ditching a particular technology and writing ‘Farewell Technology X’ style posts, it doesn’t mean that we should too.

Don’t Follow your Passion

The author of the initial post I referenced suggests to go learn something you’re passionate about in order to seek out a ‘Plan B’. I don’t necessarily agree with that suggestion. We need to be more strategic than just passion. My passion for the omgrofl programming language isn’t likely to lead to commercial success. What if you share the same passion as many others? How will you stand out? In fact, there is a book dedicated to the subject of not blindly following a passion by Cal Newport, called So Good They Can’t Ignore You. A popular quote from the book is that:

When it comes to creating work you love, following your passion is not particularly useful advice.

So what is the alternative? I recommend reading the book if that last statement has intrigued you, but in short, the hypothesis is to seek out a commercially viable niche and be so good at it, that you can’t be ignored. The book goes onto argue that the passion will come once you become competent at a particular skill or craft.

Don’t Overlook What you Already Know

You already have lots of skills that transcend a particular technology. All that time you invested in learning TDD, designing class libraries or performance tuning code is in most cases transferable to another stack.

This popular blog post from Steve Yegg titled Practicing Programming has a great practise drill for identifying your classic skills:

Write your resume. List all your relevant skills, then note the ones that will still be needed in 100 years. Give yourself a 1-10 rating in each skill.

On this point Steve concludes that: what I think you’ll likely find is that math, computer science, writing, and people skills are for the most part timeless, universal skills. Most specific technologies, languages and protocols eventually expire, to be replaced by better alternatives.

Knowing When to Change

Declining usage is not necessarily a bad thing, unless it’s combined with an overlapping high level of competition. If you are largely dependant on a technology stack, then the point at which it becomes widespread is when you should begin considering your next move, making it less relevant to you when a technology begins to lose market share. That’s not to say that we should drop a technology as soon as it becomes popular, but to always be thinking of that AND skill combination to describe our commercial offering.

A few years ago, many of the opportunities presented to me were aligned with my skill combination but required a mixture of Python, Node.js and not .Net, so I began learning those skills. There were plenty of .Net jobs available at the time, but I was also competing in a different location that had a very high level of competition for .Net technologies. I didn’t make that change because I thought Node.js was cooler, or because I thought .Net is doomed as a technology, it was about staying competitive.

I don’t claim to have a silver bullet, and each person must decide their next step based on their unique combination of skills specific to their local market conditions. So to you, my younger self, don’t overlook the classic skills you already have and always think about improving those skills, don’t get scared, get competitive, always stay in Beta. And if you’re still programming in VB6? Go in to work tomorrow and increase your daily rate…

Photo credit:

Don't miss out on the free technical content:

Subscribe to Updates


Bradley Braithwaite Software Blog Bradley Braithwaite is a software engineer who works for the search engine He is a published author at He writes about software development practices, JavaScript, AngularJS and Node.js via his website . Find out more about Brad. Find him via:
You might also like:
mean stack tutorial AngularJS Testing - Unit Testing Tutorials