To Have or Not To Have

To Have or Not To Have

by Grey Staples
Camelback Systems

Many times I have had to ask, or have been asked the same question: "Do you (or I) have..." Then follows a list of acronyms, names of software products, computers, etc. Our profession has shortened the question "does this person 'have' the requisite competence, and experience, needed for the job" into a single word. A person's professional career consists of a list of codes and claimed years of experience.

Let's consider what it takes to 'have', say, COBOL or Visual Basic or Web skills. First, there is the self assessment answer of "yes I 'have' it." Then there follows words on a resume showing recent involvement with the software for enough years to present expertise. The value of that experience is usually determined by a voice to voice or face to face interview. Sometimes a technical test is administered. The claim of 'having' it gets you in the door, after that ...

A major difference is between employment and contracting. Employees are expected to 'have' some capabilities, and be able to learn the rest. On the other hand, contractors are to 'have' everything needed, do the job, and get out.

What degree of involvement with the software actually justifies the claim of 'having' it? Who determines the extent of competence in it? One test is if the person can start work and be immediately productive. Do I have to train you or has someone else made that investment? When contracting the 'do you have' question asks how long have you used the product, rather than determining if you have the capability of learning the product. Present functioning, yes, future worth, no.

There is an old saying about a candidate with three years of experience: "Sure, six months, five times over." How long before you 'have' it depends on the age of the product. One year is adequate for new products for junior or programmer levels, while the need is for over two years experience for higher levels and older products. If the request is for years of experience in a product just released last year, you get an amused reaction. The developers are already spoken for. Perhaps this offers an insight into the knowledge of those making the request.

My favorite is the Skills Matrix which gives you pages of software acronyms and asks for how many years you've used each. I once added up the years and came away with 130 years of total experience. Clearly the wrong question was being asked.

Now, the question is how long before you lose it, or no longer 'have' it? After two years of being away from current use you become questionable. After five years of inactivity you can forget being a candidate. On the other hand, I know those who had been away from an old mainframe system (IMS - Information Management System from IBM) for ten years and were able to resume their level of competence within a few days.

If you 'have' it, work to keep it. If you don't, work to 'get it' on your resume. Years using it is all that counts. Remember that this year's 'must have,' can be next year's 'so what.'

Originally published in the Arizona Software Association's newsletter, 1996. (9-5-2001 webstat)