DON’T BE TYPECAST AS A
A koder with attitude, KV answers your questions. Miss Manners he ain’t.
I would like to think that learning more will help me
in my everyday job of writing glue and customization
code at a systems integrator. But the obvious applicable
knowledge is specific to tools and packages that may
become obsolete or discontinued even within the lifetime
of the project, and in some cases have already reached
Kode Vicious’s temper obviously suffers from having
to clean up after the mistakes of his peers. What would
he have them learn now so that he can look forward to a
graceful and mellow old age?
Looking to Learn
While your concern for my old age is touching, I have to
say that the only way I can see being mellow in my old
age is with prescription help. I keep thinking that age will
actually mellow me, but, alas, as longtime readers of KV
can tell you, that does not seem to be happening.
Let’s turn now to your question, which I would sum
up as, “How do I avoid being typecast as a software developer?” Most people understand typecasting in terms of
television or movies, where an actor plays the same role
so often that that’s the only role the actor is ever offered.
Christopher Lee, who until he was cast in the Lord of the
Rings trilogy was always the creepy and scary character
in what we now think of as campy horror films, comes
almost immediately to mind. I’m sure you can think of
similar actors and actresses.
Being typecast as a developer is what happens when
you keep taking the same jobs and doing the same things
HAVE A QUESTION FOR KODE VICIOUS?
E-mail him at
email@example.com. If your question appears
in his column, we’ll send you a rare piece of authentic Queue
memorabilia. We edit e-mails for style, length, and clarity.
that you have always done. Now, of course, it’s difficult
to get a job doing something that you have no experience with, since most employers ask that you be fluent
in whatever particular niche they are working in. I am
certainly not encouraging you to lie or pad your resume.
All that being said, there are a few things you could do,
some of which I’ve mentioned before, but never in a
The biggest thing that I encourage all engineers to
do is to keep learning about their craft, which does not
mean running out to ask your boss to send you to a
bunch of conferences or classes. Not that conferences
and classes aren’t useful, but I’ve seen far too many
people waste time and money going on junkets that have
very little to offer.
The easiest thing you can do is to join a professional
society—say, ACM. No, I was not required to say that.
Happily my editors can rarely find me in person when
I’m writing these pieces. They just don’t like the kind of
places I hide out in. KV’s alter ego has been a member of
ACM, as well as Usenix and IEEE, since his college days.
Student memberships are cheap because all three of these
groups have learned the pusher’s creed, “First hit is free.”
Once you’re hooked, well, let’s just say it’s hard to quit.
I always encourage people to subscribe to a journal or
two and to read the abstracts of papers in areas they’re
interested in. Not full papers, because who has the time?!
If you read the majority of most abstracts, you’ll have an
idea of what’s going on in your area and you’ll also find
things that are only tangentially related, which are new
avenues to study.
What I think you’re most curious about, and it’s an
important thing to be curious about, is the mix of tools
vs. techniques. A tool is something like a specific language or computer program. A technique is more general,
and can be applied across any of a set of languages. For
example, Python is an OO (object-oriented) language—
one that I happen to enjoy—but I am more interested
in how to apply OO techniques in any language than in
focusing only on Python. I often find that many people