The concept is simple economics: supply and demand. Ideally, you'd like to be a developer with skills that are high in demand, where there isn't yet much supply. That gets you jobs, and higher paying ones at that.
Over a year ago, we mentioned how
searching for jobs for skills that aren't available offshore can show you the technologies that meet that criterion. That was in relation to "choosing the right market" for yourself, but it's a good strategy for staying sharp too.
The theme in this part of Chad Fowler's
MJWTI is reiterated here: don't
rest on your laurels. You have to be proactive about keeping your skills up-to-date. Paying attention to the market, and acting on the knowledge that's available regarding the "in" technologies will help you do that.
Chad tells a hypothetical story about the demise of Java:
What if, for example, Sun Microsystems started showing signs of going
under? Java isn't an open standard. It is dictated and developed by Sun.
At any point, a dying Sun might attempt to suddenly make its language
and virtual machine into a last-minute profit center. They might introduce
incompatible changes or suddenly change the license restrictions of Java,
causing an industry panic followed by a mass exodus.
With your head in your monitor coding, you might not even hear about
something like this until it was too late.
What if you're a Flash guru and Microsoft's Silverlight comes pre-installed on 98% of the computers in the world as Adobe's Flash loses the support of management? Will Flash maintain it's market share? What if Adobe drops support for ColdFusion? Will the open source world carry the torch? What if Microsoft decided .NET isn't going to cut it for the next generation of programming paradigms, and scraps it? Will your skills in .NET be valuable for as long as your career keeps you working? What if management decides they want to standardize on
a cross-virtual-machine dynamic functional language called Fan, and they want to keep the familiar curly-brace-and-semi-colon syntax? Will you still be using Ruby, Python, or Perl at your day job?
Are you willing to take those chances?
The most likely scenario is that these technologies will continue to exist, as they slowly fade away into the Next Big Things. As Chad notes,
Even more likely is that, comfortable in your current job with your current
set of skills, you might remain blissfully ignorant of the Next Big Thing as
it rolls in. Ten years ago, you would have been surprised to find out just
how big object-oriented languages with garbage collection would become.
But, there were definitely signs if you were watching.
Ten years ago we couldn't have done the work with DNA and large genomes that we can do today. More interesting problems (in bioinformatics and elsewhere) are able to be solved by more people just because of increases in memory, processor speed, disk space, and number of processors. What are you doing to learn about concurrency? What are you doing to learn about optimizations you can make? When constant-factor reductions in processing time save days to weeks of computations, it's not premature to make them.
Are you watching?
Hey! Why don't you make your life easier and subscribe to the full post
or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate
wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!
Leave a comment
Agreed we as developers can never let our skills lapse. Not keeping up with the market or technology will make you a Dinosaur. That is one of the reasons that this job is difficult because of the constant learning and training it can take a toll on things after a while. When you work a long day then come home spend time with family or personal the last thing you want to do is crawl back onto the computer and work more.
I like some developers have fallen into that trap and when wanting to look for a new job found that the market is just not there with skills that maybe a bit dated. So now I play catch up and hurry to learn a ton.
Posted by Eric Lewis
on Aug 15, 2008 at 12:06 PM UTC - 6 hrs
@Eric Lewis: Back in January I mentioned I wanted to set aside some "practice time" each week for writing code and learning new technologies. Except for the first couple of weeks, I haven't really stuck to it.
Still, I've had some time to learn things as I go - just no real structure to it that I can identify off the top of my head.
Your last paragraph gives me the idea for a post. Mind if I quote you (and attribute it)?
Posted by
Sammy Larbi
on Aug 15, 2008 at 01:04 PM UTC - 6 hrs
