With technology always changing and new languages/updates an everyday happening should a developer always stay on the cutting edge? (now let me explain)
I ask this because I work for a company that is just now going to XP pro. They run the office 2003 suite and just now upgraded to .net 3.0 My skill set covers a somewhat limited range, but have been focusing on c# and app development. My company employees over 20,000 people nationwide so change is a rather slow process and therefore cutting edge is not what I get to learn.
I want to keep my skills up but I feel that by not learning the most current changes in my chosen speciality I might be limiting my employment ability in the future. i can see the argument on both sides. Larger companies typically move at a slower pace while the smaller ones tend to be on the cutting edge especially in web development. I can't even imagine when they intend to even look at sliverlight or sharepoint 2007.
I share your feelings. When I have worked on projects requiring a security classification, I've had to use 10-year-old (or older) tools. (There's a reason for that -- it takes time for the authorities to develop confidence that a new tool will not contain hidden surprises, and if I were in their shoes, I'd probably do exactly what they do.) That doesn't mean it's not fun, but I've felt kind of left out as well. It's a bit like seeing new movies only after they come out on DVD.
My suggestion is (and I'm doing this myself) to get copies of the newer tools and work using them on your own projects, on your own time (Saturday mornings work well for many college professors, who teach during the week and do much of their research on weekends). Microsoft's .NET development kits are free of charge, as are the Express versions of Visual Studio and SQL Server. Or you might prefer playing with open-source tools -- I have a copy of GIMP, a graphics program that one can modify using code written in Scheme.
BTW, I've been using C# for a couple of years now and just love it. It may seem restrictive in some ways, but those same restrictions help to make the code very easy to read. There's a bit of overhead, but not enough to bother me, and the built-in error checking is very valuable. When I was a consultant at a university computing center, maybe 2/3 of my customers had run into trouble because they'd read (or worse, written) past the end of an array in a FORTRAN program. Perhaps they could have routinely added code to each array reference to check for overflow, but that would have cluttered the listing and taken time to put in (something like adding lots of Debug.Assert() statements nowadays)... so their programs simply crashed, often in strange and marvelous ways, and they'd waste a day or two tracking down what had happened. :-(
I tend not to be a "cutting edge" adopter of new tools, am more of an "early" to "middle-of-the-road" adopter. If you are on the cutting edge, you may spend time learning to use tools that you'll never actually employ -- but if you're not on the cutting edge, you may miss out on opportunities to use them just through being unfamiliar with what they might be able to do for you. For example, VisiCalc, an early spreadsheet program, wasn't very popular with developers because they could easily do in BASIC what one might do in VisiCalc, and BASIC could do much more besides. But VisiCalc was very easy to use, it and other spreadsheet programs quickly became very popular, and much software was developed based on them... but many BASIC-only developers missed the opportunity to develop this spreadsheet software because they lacked familiarity with a valuable new tool. So I hope you at least attempt to stay familiar with the newer tools. Good luck.