Managing Your Skills Portfolio
There's no right answer to "What technology should I learn next?" But there is a way to manage your skills to maximize the return you get from them.
One question that periodically crops up when I'm teaching is, "What technology should I learn next?" The real questions are, however, "What skills should I be developing?" and "How much time should I spend on each?" You can only answer those questions by dividing your skills into three categories: obsolete, current and developing. These form your skills portfolio and each requires a different investment of your time and attention (I'll refer to that investment as your personal "growth time").
Obsolete skills are those skills whose demand has stopped growing: No organizations are needing these skills and the organizations currently using these skills are using them purely to maintain existing applications. The demand for these skills is stable or shrinking.
The problem with obsolete skills is that you can make a living with them -- in some cases, a very good living. There are, for example, many COBOL developers keeping critical applications going right now and they're paid very well for it. On top of this, while the current crop of COBOL programmers is leaving the workforce (retirement and death), the world isn't producing more COBOL programmers. If the organizational needs that depend upon COBOL programming skills aren't shrinking as fast as the pool of COBOL programmers is, then salaries for developers with these skills may actually go up.
The competition for these skills among employers is low. Companies that don't have a need for these skills have no intention of developing those needs and, worse, feel that developers with those skills are overpaid. This means that developers with these skills can only move between a limited number of companies, and the turnover in these companies for developers with these skills is very small (the organizations have all the developers with these skills that they need). But the real problem is that these skills don't lead anywhere: Organizations assume these developers aren't interested in the ongoing changes in software development; obsolete skills aren't considered steppingstones for new jobs.
Making a living from obsolete skills makes sense if you're close to retiring. These skills can even provide you with some post-retirement consulting income from your old employer. However, if you aren't close to retirement, you don't want to be making your living from obsolete skills: There's no professional or salary growth associated with these skills. You should not be investing any growth time in these skills and should be trying very hard to reduce the contribution these skills make to your income by getting employers to pay you for other skills.
The tough part is, effectively, abandoning skills that you've identified as obsolete even though you're making good money from them. Unless you're close to retiring you can't afford to work for an employer who values you for your mastery of obsolete skills. You need to leave these employers before other, potential employers regard you as uninteresting.
Current and Developing Skills
Current skills are skills that are in demand in the market and where the demand is growing every year. There might not be a lot of employers that need these skills, but either the number of employers is growing or those employers need more developers every year. There is a well-known pay rate for owners of these skills and the productivity/output of developers with these skills is also well known.
Usually, there are many organizations that want these skills, so developers have a variety of places they can work; because the demand is growing, the number of options available to developers grows every year. These skills are also considered the focus of progress in software development and, as a result, these skills are considered steppingstones to other skills and jobs.
You want to invest most of your growth time in your current skills. You want to advertise your ability with these skills to your peers and management (asking for training is one good way to do that). Most of your current income should normally be coming from these skills and these are the skills that should displace the skills you've identified as obsolete. You need to be working for employers who value you for your mastery of current skills.
Finally, I come to developing skills. Not a lot of organizations are interested in hiring developers with these skills…but some are. The demand for these skills is undetermined, no pay rate is set (yet), and the productivity of programmers with these skills isn't known (at least, not yet). Developers who invested in Big Data skills three years ago are probably very pleased with both their current jobs and their job prospects.
Developing skills will, eventually, end up in one of two categories: current or obsolete. Based on my experience, most developing skills end up in the obsolete category (anyone remember artificial intelligence, though the new category of smart apps might be building on those skills). Some developing skills, however, will become current (like SharePoint or the .NET Framework itself).
The problem with developing skills is that it's impossible to know which ones will become current skills. People who claim they can spot which technologies will become current are just plain lucky (although those who invested in Big Data three years ago will claim they were prescient).
You should be investing about 20 percent of your development time in a developing skill. Most of your developing skills will end up being obsolete skills so, every year, you should assess whether it's worth continuing your investment or abandoning the skill for some other developing skill. Every once in a while, one of these developing skills will pay off for you and you will do very well with it, until it becomes a current skill. Even then the skill will serve you well, but it will be time to start looking for your next developing skill.
Which leads to the next question: "How do I develop my current and developing skills?" I'll come back to that topic in my next column.
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.