kode vicious
Dear KV,
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 this destination.
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
Dear Looking,
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 kv@queue.acm.org. 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 single reply.
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
References:
Archives