In my October and November 1999 editorials (see "What’s an Expert?" and "You’ve Got to Have Friends," respectively), I described how I felt that each of us was going to have to become a specialist–a wizard–in a limited number of the technologies that we use. Which leads to the question, "How do you pick which areas to specialize in?" Often, the force of circumstances and the decisions of your clients or managers will answer that question. However, you’ll always have some freedom to determine where you should invest your training time. The key word is "invest." You spend time on learning a technology because it will pay off down the line in three ways: doing work that you like, gaining rewards (status, money, benefits), or ensuring job security. You might learn a particular technology because of an immediate, specific need (for example: get this project out the door), but, to succeed in the long run, you need to regard your training as an investment rather than a quick fix.
A serious investor doesn’t buy just one stock but, instead, builds a portfolio. The portfolio is balanced so that as one stock starts to decline, another will start to do well. A well-balanced portfolio gives you time to move out of a declining investment area before incurring large losses. Your portfolio of skills must also allow you to do well in the short run (the next year), while ensuring that you’ll do well in the long run (the next five years).
I classify the skills in my portfolio as mature, niche, obsolete, and developing. Mastery in any one of the skills in my portfolio can lead to doing work that I like. However, the ability to stay employed or make big money is dependent on not only which skills I have, but also the types of skills.
Mature skill reflects long-term value. Mature skills are easy to identify: Many other developers have this skill, it’s easy to tell who’s good and who’s bad, the price people are willing to pay for that skill is well-known, and demand for the skill is stable or growing modestly. My current mature software skills include VBA programming and database design. Since my productivity in using these skills is known, I charge by the hour (well, by the day, actually). Mature skills are job-security skills if you’re competent in them.
Niche skills are also easy to identify: They’re the ones where demand outstrips the supply. Frequently, determining competence in niche skills is difficult, so it’s easy to get "good enough." Because of the high demand, you can often charge an hourly rate for niche skills even though your productivity isn’t guaranteed. A niche skill is a big money skill because the bidding war for the few people who have the skill drives up prices. My knowledge of Microsoft’s i*net development tools (particularly the client-side tools) is one of my current niche skills. Niche skills aren’t job-security skills because the demand is unstable, the measure of competence changes frequently, and supply grows rapidly as the high salaries attract new entrants. Should supply meet demand, a niche skill becomes a mature skill, with the resulting drop in salaries.
Obsolete skills are skills that aren’t in demand anymore. My knowledge of DL/1 falls into this category. Obsolete skills can never be high-earning skills. If your price gets too high, your clients will simply move to a technology that uses cheaper mature skills. However, obsolete skills are frequently skills used in jobs that you like. If you didn’t like the job, you probably would have found a way to move on. Obsolete skills aren’t job-security skills (no matter what your employer tells you) because the attraction of new technology is so high.
Developing skills are the ones that you’re just learning. Your competence is weak by anyone’s standards, so demand is irrelevant. Since your productivity is unknown, you have to charge a flat rate for any projects that you work on (and you probably can’t guarantee a delivery date). You invest in developing skills because you hope that they’ll turn into mature or niche skills. For me, XML is a developing skill. As I discovered with Artificial Intelligence, it’s also possible for a developing skill to turn right into an obsolete skill.
You have to invest time in two areas: keeping current in your mature skills and learning developing skills. Should the price for your mature skills start to decline (as my database design skills will when object databases ramp up), one of your developing skills will take up the slack. Should one of your developing skills turn into a niche skill, you can take time from your mature skill to increase your investment in it. If the niche skill becomes mature, you’re no worse off than if you’d invested in one of your other mature skills. If your niche skill becomes obsolete, it typically doesn’t take long to catch up in a mature skill. You must never take time away from your developing skills.
How do you pick which skills to develop? There’s no easy answer to that question. The only real answer is to dabble in a few and concentrate on one or two. You have to keep your eye on the marketplace to determine when it’s time to drop or pick up a new developing skill. I’ve dabbled in more skills than I’ve fully developed, but some of my investments have paid off. I’ve never yet had a really valuable niche skill, but I keep hoping. I have, however, always had a mature skill that would let me earn a good living while doing work I liked.
Changing the topic, in my September editorial, I noted that I object to using arbitrary numbers–especially Autonumbers–as the primary key in a database. I’ve received several letters on this topic since then and ended up participating in a discussion on the issue in the comp.databases.msaccess newsgroup. I thought that all of the issues got a good airing in the various postings. The entry point is a post called "Do you object to Autonumber type for Primary key?" from Danny Lesandrini. If you want to use Google Groups to follow the discussion, you can find a tree view of the whole discussion at this location