Slashdot Mirror
Your Tech Skills Have a Two Year Half-Life
itwbennett writes "Eric Bloom, an IT leadership coach and former CIO, has answered that eternal question 'does working on old software hurt your professional marketability' with a somewhat surprising 'no.' But, Bloom adds, 'a techie's skill set from a marketability perspective has a two year half-life. That is to say, that the exact set of skills you have today will only be half as marketable two years from now.'"
I still program in Java which I've been doing since 1998. I also sometimes program in Python which I've been doing since 1997. Obviously some things about those languages have changed, but many things haven't.
OO languages are fairly similar to what they were 10 years ago. As is OO design, etc. There have been large changes to frameworks etc, but there is a significant "core skill set" which transfers over.
In my case, my skills have not become become less marketable at all over the last two years. Recently I spent two years out of work (voluntarily), and when I returned to the job market I had no problem whatsoever finding a job.
I think the half-life of skills is more like 15 years.
Even COBOL refuses to die. C, C++ and it's variants are still everywhere (Objective C for Apple's iPhone App Store) decades later. Java has outlasted the fads of Ruby and Rails. HTML has been around ... well ... since the Internet. Javascript continues to be the #1 web scripting language.
So no, your skills don't have a half-life of "X" number of years.
Suppose I know some amount (X) of C now (Just out of college)
Will that be less valuable after having 2 years experience in the field?
No, it wont. He's talking about *certain* IT skills. I'm going to go out on a limb and bet he's referring to the kind of tools you learn in a simple ITT-Tech type certification program.
PS: I don't reply to ACs.
I do not know why this is in the front page, and I do not know why the educated crowd of Slashdot listens to BS from the CIO/CEO/CXO of the day and his new genius theory to quantify things he should not, mainly because he does not understand what technology is about. These guys should be in marketing. There are new technologies and old technologies, and jobs for all of them if you are good and know the right people. If you are very good at Fortran or Cobol you can get a job. If you excel at Java or C you can get a job. None of these are new technologies by far, and the skills are highly portable from one to the other. The basic knowledge you need is always sort of the same, a mix or common sense, knowledge of the basics (algorithms, data structures, and a brief background on the problem domain you are working on), and some minimum social skills.
My experience has been that one has to balance keeping up with one's technical field and avoiding chasing fads. Too often "keeping fresh on new tech trends" boils down to chasing fads and, for instance, using a new language because it is there. What I have concentrated on are the technologies needed to solve difficult customer problems as they push their own application and technological domains. To make this work I keep up a constant cycle of study-learn-work-produce. That has worked well for 35 years and keeps me in demand as a senior research engineer (Ph.D.) at 60 years of age.
It also depends on when you're talking about. After the Dot-Com crash, Java programmers were hurt FAR, FAR worse than C or Fortran programmers. Shortly before Y2K, Fortran and Cobol programmers were in massive demand. (For those who argue Y2K was a hoax because nothing happened, I'd point out that after a large fortune and a larger army of coders went to work on fixing the bugs, you should have EXPECTED nothing to happen. Fixing problems after the disaster is too late.)
So the decay curve isn't a simple one. It has bounces and bottomless pits along the way.
However, and I can't stress this enough, staying current isn't merely a matter of learning the next feature of the old language set. To stay relevant, you MUST diversify. A coder should also be a damn good system admin and be capable of database admin duties as well. Being able to do tech writing as well won't hurt. You don't know what's going to be in demand tomorrow, you only know what was in demand when you last applied for work.
Programmers and systems admins shouldn't specialize on one OS either. As OS/2 demonstrated, the biggest thing out there in week 1 can be a forgotten memory by week 12. The market is slow at some times, fickle at others. You don't know how it'll be, the best thing you can do is hedge your bets. If you've covered (and stay current on) Linux, a BSD Unix variant, a SysV Unix variant, Windows Server, and at least one RTOS (doesn't matter which), you'll know 98% of everything you'll need. You can learn the specific lingo needed by a specific OS implementation quickly because that's only a 2% filler and not a 100% learn from scratch.
Although workplaces don't do sabbaticals (which is stupid), you should still plan on spending the equivalent of 1 study year for every 7 work years. (If you spend 1 hour a day practicing, relearning, or expanding your skills excluding any workside stuff, you're well in excess of what is required. I can't guarantee that an hour a day will make you invulnerable to downturns, but I can guarantee that there will never be a time, even in the worst recession, that your skills aren't in demand.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
One simple way to avoid that type of shit from entering the workplace, refuse to hire anyone that has a technical certificate of any kind along with those with a degree from the diploma mills such as ITT Tech and Conservative err Community Colleges. Community Colleges are a fancy way of saying trade school. Employers should only hire the truly educated and those are only from the major Universities.
I work in higher education, and not for a for-profit or a community college. Your belief that graduates from "the major Universities" are somehow better than those from other institutions, especially for something like application development, is hilarious to me.
Space game using normal deck of cards: http://BattleCards.org
I suspect that the Bloom is referring 'tech' skills in a general sense. Most IT people are not programmers, and thus consume rather than create software products. If you have 'skills' using Office version X, it will probably not be as valuable in two years when a new and improved product, Office X+1 comes out.
.Net have been around awhile and are not going to go away.
Obviously, if you think of IT as just programers, what he is saying makes no reals sense, since staples like C, Java, and
HA! I just wasted some of your bandwidth with a frivolous sig!
As a programmer, I can say that programming itself, that is, *how* to write code, in terms of methodology -- is a skill that will never leave you once you have acquired it (so long as you keep using it).
Almost any programmer worth their salt can learn a new language in a few weeks, if not days. Granted it may take more time to develop understanding of any idioms or warts the language may have, but you can learn that stuff on the fly, unless you're writing HA/mission critical code, in which case, there'd better be a review process, and it's reasonable to expect that someone on the team will be an expert in the technology being used.
So I'd say unless you've given up programming entirely and have moved on to a different career, your skills are still valuable, and will stay reasonably "fresh" even if you're writing code in a 30-year-old language (as the article says), as long as you actually think while you write code, and aren't just a copy/paste/munge wizard, not that there's anything wrong with that, for certain kinds of things.
This of course doesn't even consider the (imho) much more valuable part of being a software developer: being able to converse with non-technical people, in whatever human language you use, and then translate that into some sort of actionable programming work. That's often more than half the battle. Then of course there is testing, testing and testing.
The article isn't completely wrong, but (like much of the "IT industry") I think it missed the point of what skills are actually important to doing software development. Knowing how to use a specific bit of kit is pretty far down on the list, I think, for any reasonably competent programmer/technologist.
I treat anything with the word "marketability" in it with suspicion.
I had once felt that way too, but there's a distinct difference: doctors need only keep up with advancements in medicine or new discoveries about extant biological systems: the human body itself, however, doesn't really change (not over a few millenia, anyhow). It's a relatively stationary target.
Software, OTOH, frequently changes drastically and constantly; it's engineered by man, and can be radically altered in any number of ways on whim, forcing a reinventing of the wheel sometimes even; a moving, morphing target, much of it probably driven as much as by planned obsolescence and profit as it is utter necessity. (Does Word really need to keep "evolving" to do what it does?) Sometimes I really wanna say "screw all this" and go start a goat farm.
Look back up at my post, now look back down, you're on the Internet. Now look back up. I'm a signature.
Half-life is still a pretty damn good analogy.
It is one of those mysterious, non-intuitive things about the subatomic world. You see, rather than ageing uniformly, atoms randomly decide whether to decay or not. Meaning that if you have a container filled with plutonium, after 24,100 years half of the atoms would have decayed, the supply in the container has decayed as a whole, but in reality half of the atoms there never decayed at all.
The result of the analogy is that every two years half of the programmers will be unmarketable (unless they acquire new skills) the other half however doesn't need to learn anything since their exact skill set is still in demand.
But... the future refused to change.