Your technical skills are obsolete: now what?

One day you go to work and discover your technical skills are obsolete:

• The programming language you know best has been declining in popularity for a decade.
• The web framework you know best has been completely changed in v2, and rewritten in another language for good measure.
• Job postings are stomach-churning lists of tools you’ve never used, or even heard of.
• You’re asked to compare two technologies, and you don’t know where to start.

You feel like your growth has been stunted: there are all these skills you should have been learning, but you never did because you didn’t need them at work. Your coworkers seem to know all about the latest tools and you don’t, and eventually, maybe soon, you’ll just be left behind.

What should you do? How can you get out of this mess and salvage your career?

I’m not going to say “code in your spare time”, because that’s not possible for many people. And while I believe it’s completely possible to keep your skills up-to-date as part of your job (e.g. I’ve written about having a broad grasp of available technology and practicing on the job), the assumption at this point is that you haven’t done so.

Here are your goals, then:

1. Get your technical skills up to speed, and quickly.
2. Do it all during work hours.
3. End up looking good to your manager.

In this post I’ll explain one way to do so, which involves:

• Understanding the organizational dynamic that causes organizations to use out-of-date technology.
• Actively seeking out these problematic technologies, and then improving the situation both for your organization and for you.

Why you’re using old technology

Most programmers, probably including you, work on existing software projects. Existing software projects tend to use older technology. The result: you are likely to be using older, out-of-date technology, rather than the latest and (speculatively) greatest.

When a project gets started the programmers in charge pick the best technology they know of, and hope for the best. After that initial set of choices most projects stick to their current technology set, only slowly upgrading over time. Of course, there’s always new technologies coming out that claim to be better than existing ones.

Updating an existing project to new technologies is difficult, which means changes are often put off until it’s truly necessary. It takes effort, ranging from a small effort to upgrade to a newer version of a library version, to a large effort for changing infrastructure like version control, to an enormous effort if you want to switch to a new programming language. So even when a clearly superior and popular technology becomes available, the cost of switching may not be worth it. Time spent switching technologies is time that could be spent shipping features, after all.

Two real-world examples of this dynamic:

• The Twisted open source project was started in 2000, and used the CVS version control system. Subversion, a superior version control system, was released the same year, and soon new open source projects defaulted to using it. Eventually Twisted switched to Subversion. And then Git was released, and eventually when it was clear Git was winning Twisted switched to Git. In both cases Twisted’s adoption lagged behind new projects, which could easily start off using a better VCS since they didn’t have to pay the cost of upgrading existing infrastructure.
• A large company, founded in 1997, built the initial version of their software in Perl. At the time Perl was a very popular programming language. Over the past 20 years Perl’s mindshare has shrunk: it’s harder to hire people with Perl knowledge, and there’s less 3rd party libraries being developed. So the company is stuck with a massive working application written in an unpopular language; the cost of switching to a new language is still too high.

The switch to new technology

Eventually the cost of sticking with an old technology becomes too high, and management starts putting the resources into upgrading. In a well-run company this happens on a regular, on-going basis, and management will have spent the resources to keep programmers’ skills up-to-date. In these companies learning about new technologies, and then deciding which are worth the cost of adopting, will be an ongoing activity.

In many companies, however, the cost of keeping programmer skills up-to-date is dumped on to you. You are expected to spend your spare time researching new programming languages, tools, and techniques. If you enjoy doing that, great. If you don’t, your technical knowledge will stagnate, at some cost to the company, but even more so to you.

Helping your project, upgrading your skills

If you find yourself in this situation then you can turn your project’s out-of-date technology into a learning opportunity for you. Technology’s purpose is to solve business problems: you need identify business problems where your current technology isn’t working well, and try to solve those problems. This will allow you to research and learn new technologies while helping your project improve.

Specifically, you should:

1. Identify obsolete and problematic technologies.
2. Identify potential replacements.
3. Convince your manager that this is a problem that merits further resources. Your goal is to get the time to build a proof-of-concept or pilot project where you can expand your understanding of a relevant, useful new technology.

If all goes well you’ll have both demonstrated your value to your manager, and been given the time to learn a new technology at work. But even if you fail to convince your manager, you’ll have an easier time when it comes to interviewing at other jobs, and some sense of which technologies are worth learning.

Let’s go through these steps one by one.

1. Identify obsolete and problematic technologies

Your project is likely using many out-of-date technologies: you want to find one that is both expensive to your project, and not too expensive to replace. Since you’re going to have to convince your manager to put some resources into the project, you want to have some clear evidence that an obsolete technology is costing the company.

Look for things like:

• Technologies that are shrinking in popularity; some Google searches for “$YOURTECH popularity” can help you determine this, as can Google Trends.
• Repetitive work, where you have to manually do the same task over and over again.
• Trouble hiring people with pre-existing knowledge.
• The system everyone knows is broken: it crashes all the time, say, or corrupts data.

You can do this while you work: just look for signs of trouble as you go about your normal business.

2. Identify potential replacements

Once you’ve identified a problem technology, you need to find a plausible replacement. It’s likely that any problem you have is not a rare problem: someone else has had this issue, so someone else has probably come up with a solution. In fact, chances are there are multiple solutions. You just need to find a reasonable one.

You should:

1. Figure out the keywords that describe this technology. For example, if you need to line up images automatically the term of art is “image registration”. If you want to run a series of long-running processes in a row the terms of art are “workflow management”, “batch processing”, “data pipelines”, and other terms. You can do this by reading the documentation for some known solution, talking to a colleague with broader technical knowledge, or some search engine iteration.
2. Once you have the keywords, you can start finding solutions. The documentation for a tool will often provide more keywords with which to extend your search, and will often mention competitors.
3. Search engine queries can also find more alternatives, e.g. search for “$SOMETECH alternatives” or look at the Google search auto-completes for “$SOMETECH vs”.
4. Once you have found a number of alternatives, get a sense of what the top contender or contenders are. Criteria might include complexity, maturity, risk (is it developed only by a startup?), features, popularity, and so on.

The goal is become aware of the range of technologies available, and get a superficial understanding of theirs strengths (“React has a bigger community, but skimming the Vue tutorial was easier”, for example). This process can therefore be done over the course of a few hours, at most a day or two, during your work day in-between scheduled tasks.

Remember, you can always rope in a colleague with broader technical knowledge to help out: the goal is to improve things for your project, after all.

3. Getting management buy-in

At this point you should have:

1. Identified a problem area.
2. Identified a technology or three that might solve this problem.

Next you need to convince your manager that it’s worth the cost of trying out a new technology. In particular you need to:

• Demonstrate there’s a real problem.
• Suggest a potential solution that will solve the problem.
• Give some evidence this solution is reasonable, and not too expensive.
• Suggest a next step that will allow you to investigate further (and learn more!). Ideally, some sort of pilot project where you can try the technology out on a small scale and see what it’s like using it in practice.

Your pitch might go something like this:

Demonstrate the problem: “Hey, you know how we have all these problems with Foobar, where we spend all our time redoing the formatting instead of working on actual features?”

Suggest a solution: “I’ve been looking into it and I think the problem is that we’re using a pretty old library; it turns out there’s some newer tools that could make things easier.”

Evidence for solution: “For example the Format.js library, it’s got a huge userbase, and from the docs it’s pretty easy to use, and see this example, that’s exactly what we waste all our time on doing manually!”

Next step: “So, how about for that small project we’re doing next month I try this out instead of our usual Foobar setup, and see how it goes?”

If your manager agrees: success! You now have time to learn a new technology in depth, on the job.

If your manager doesn’t agree, all is not lost. You’ve gained awareness of what newer technologies are available; you might spend a little spare time here and there at work learning it more in depth. And when you next interview for a job, you’ll have some sense of technologies to either brush up on, or at least to mention during the interview: “Formatting? Oh, we used Foobar, which is pretty bad because X, Y and Z. But I did some research and found Format.js and it seemed a lot better because A, B and C. So that’s what I’d use in the future.”

Don’t just be a problem solver

The process I describe above is just one approach; no doubt there are others. The key skill involved, however, can’t be replaced: learning how to identify problems is critical to your success as a programmer.

As a junior programmer you get handed a solution, and then you go off and implement it. When you’re more experienced you get handed problems, and come up with solutions on your own: you become a problem solver. In many ways this is an improvement, both in your skills and in your value as an employee, but it’s all a dangerous place to be.

If you’re a junior programmer no one expects much of you, but once you’re past that point expectations rise. And if you’re only a problem solver, then you’re at the mercy of whoever has the job of identifying problems. If they fail to identify an important problem, like the use of an old technology, or decide your career isn’t a problem worth worrying about, then you might find yourself in trouble: working on a failed project, or lacking the skills you need.

Don’t just be a problem solver: learn how to identify problems on your own. Every day when you go to work, every time you look at some code, every time you see a bug report or a feature request, every time you feel bored, every time someone complains, ask yourself: “What is the problem here?” As you learn to identify problems, you’ll start recognizing obsolete technology. As you learn to identify problems, you’ll start noticing the limits of your own skills and your current career choices. You’ll become a more valuable employee, and you’ll become more effective at achieving your own goals.