It’s been on my mind since reading somewhere-on-line-and-now-I-cannot-locate-it (but if/when I do I will post a link) Joel Sposky comment about promoting folk into development positions from support. Earlier this month one of the Dice Bloggers asked the question is tech support a trap? I was impelled to comment, as were others.

Years ago, when 640K was loaded, I started out building PCs. Not long after that I began working as a Programmer. In the first position “support” was an integral part of my responsibilties. In the second my primary task was programming; a secondary role was support of persons with the title of “Service Associate”. That is, they were the liaison between the clients and the group in which I worked. In both roles I received the compliment of being told I possess great “soft skills” in addition to technical ability, and that I should strive to utilize those soft skills by not sitting in a corner/office/cubicle all day writing code.

Specifically, the first recognized my ability to teach. The second recognized that I remain calm either on the phone or in person while asking (without a script !) appropriate fact-finding and information gathering questions which I used to determine the problem, or the cause of the error. A related ability is being able to examine crashed-code, determine the cause of an error, correct the code, and rerun the program so data can be processed.

Rather than re-type the comment I left on Dice, I am pasting it here:

“This I never understood: why technical (and I’ll include software) support is viewed as an entry level position. Building a network, administering a system. and writing code according to specifications are “easy”; determining the cause of a user-reported error requires a completely different skill set and talent. It’s been my experience that a minority of technically gifted folk have the necessary soft skills to excel at supporting end users. That is, they have no patience, find it difficult to speak in layman’s terms and have no idea how to ask appropriate and probing questions that get to the actual problem. It’s time for “IT” (and business in general) to stop treating support as purgatory, and promote it as a valid and valued career path in its own right.”

If you are familiar with LinkedIn you know that one of the ways to customize a profile is by listing “skills”. LinkedIn leaves it to the profile owner to determine what is a skill. Some would claim there are listed “skills” that are more appropriately labelled “tool”.

[For what it’s worth I participate on LI, Dice, TechRepublic, HBR (Harvard Business Review), The Economist and anywhere else I can post what I believe is a thoughtful comment. Therefore I’ve been able to read others (hopefully) thoughtful commentary regarding skills versus tools.]

What is a skill?

Is “C” (or whatever programming language you like) a skill, or a tool? I, and others, would suggest that programming is the skill, and “C” is a tool. Same can be said for networking; is Cisco (or any other networking solutions) networking a skill or a tool? Setting up a network is a skill; the hardware and software you use are simply tools.

I submit that if you have the talent for “technology” then you will develop the skill, and learn the tool(s) necessary. Whether it’s networking, systems, applications, or administration, if you have the talent, you can learn the skills and how to use the tools. However, let’s be honest; talent/skill in one area of technology does not mean you will excel at all areas. You might be able to do the various jobs, but there will only be one or two at which you will become very good. Can we all say “IT Generalist”?

Is Project Management a skill? I say yes. The particular PM software you choose is the tool.

Shell programming/scripting? A skill. “Bash” is one available tool.

Database programming? A skill. SQL, Rdb, etc. are tools.

Let’s frame in in the world of photography; your skill is photography, not “Pentax K10D”. The K10D is a tool.

So, I’d appreciate comments from anyone who reads this blog entry. Agree, or disagree and why?

Much hay is being made on various tech forums and blog sites about the latest and greatest thing since sliced bread; cloud computing. One of the members of the Old Geek Registry on the LinkedIn social network started a discussion titled Deja Cloud and asked: “does anyone else feel we’ve come full circle? Cloud computing is what we were doing 30 years ago.” Forbes reminds us that cloud computing is not a new idea just a new name for what’s been done in the past.

One of my first software engineering positions gave me access to a configuration known as a VAX(VMS) Cluster. Multiple systems working together to share the load, the apps and the data; my data and apps were on “servers”, not on my PC. Actually, I did not use a PC; my connection device was a VT device such as a VT 420. I dare say clustering was very cloud-like but even better. Why? Because the OS was VMS and VMS is stable, robust and secure.

Perhaps much; your title is industry standard and perfectly describes your AOR.
Perhaps little; an industry standard that is insufficient to describe your AOR.
Perhaps nothing; an industry standard, or not, that is simply a title to confer status or $.

I recently entered into an on-line discussion with a person interested in transitioning from “System Administrator” to “Programmer”. My first response was to request a definition of “System Administrator”. The reason I asked is because I know a person who told me he was a SA. When I asked him to describe his responsibilities it seemed to me he was a PC Tech. He was not creating/modifying/deleting user accounts and print/job queues, or installing system software on a multiuser system; he kept PCs running.

Tangentially, the online conversation was hijacked for a while and became a discussion about program versus script, and what is a real programming language.

Over the years I’ve held the official titles of Programmer/Analyst (various levels), Project Manager, MIS Supervisor, MIS Director. Unofficially I’ve served as Technical Support, Network Engineer, System Engineer, System Administrator, Software Engineer. There was a desire by one of my supervisors, when I was officially a Programmer, to recommend my title be changed to reflect what I actually did; System Engineering. Sadly he left and I remained, officially, a lowly programmer. However, I continued to serve in the roles of System Engineer, System Administrator, Network Engineer and Technical Support, etc.

Ultimately, I don’t care about my title. I care about enjoying what I do and recognition for being good at what I do. Being (well) paid is nice too !!!