To a greater or lesser degree each job you have will improve your knowledge of certain specific areas. At the conclusion of each, though, how marketable are you in general? If you just spent three years working with J2EE 1.4 (and let's say that the application was EJB 2.x SLSB/SFSB/BMP entity beans, servlets, JSP, XSLT/XML, and Oracle as the database), at the end of that you can't even claim any particular leg up in approaching a Java EE 5 project that uses annotations to the hilt, EJB 3.0, the Java Persistence API, dependency injection, JAX-WS 2.0, JSF and MySQL. You'd have to learn nearly as much new stuff as if you were suddenly asked to tackle a project using .NET 3.5, C# 3.0, Linq to SQL, WPF, and SQL Server Express.
Point being, every job you have is a tradeoff between general and specific marketability. In the worst case you finish a job only to find that every technology-related skill you have is obsolete (unless you find a new job maintaining the kind of project you just finished). In the best case you'll be current in a subset of technologies that are widely in use. For most developers the reality is somewhere in between those two extrema.
Think of this analogy. You're a glider pilot, and you're looking for sources of lift: thermals, ridge lift, mountain waves, and so forth. Each such source is of a given extent and strength...and duration. Your object, of course, is to stay aloft as long as you can. If you extend the analogy by saying that one horizontal axis is time, and the other is specific technologies, and the vertical axis is market share, the slowly expanding 3D image of "thermals" (expanding because the number of technologies increases, and time advances) provides a view of what you, as the glider pilot, have to do. Maybe you'll end up in a powerful thermal of just one major technology but extended duration, and ride that for ten years, just to get dumped out as that thermal suddenly collapses, and the nearest thermals on the technology axis are now a good distance away. Or perhaps you'll keep your glider in a wide technology area with many weak thermals, closely spaced, each lasting for a few years...as one wanes and stops providing lift it's a short hop over to the next.
It's a way of thinking of the constant juggling act involved in professional software development. There are a lot of coders out there who have felt like fish cast up on a beach by an especially big wave at high water, and now they're left gasping on wet sand as the tide recedes. "Hmmmm, maybe I shouldn't have specialized in CORBA", or, "becoming a guru of TeX seemed like a good idea at the time, but..."
How do you prepare yourself as best you can for keeping yourself aloft? A lot of jobs out there keep you stuck in one spot. You learn a fair bit at first just to get up to speed, then over the years you slowly become a true expert in...well, not much. For example, you may become a Zen Master of the latest servlet API and HTTP 1.1, but unless you're writing web containers that really doesn't give you any practical advantage over a competent programmer who spends a few weeks immersed in either spec.
In other words, most jobs don't really give you time during working hours to do much, if any, professional development. You just get better at a few things, and you fervently hope they stay popular (and hence marketable) in the outside world. You certainly don't have much time of your own to put into learning new skills - not unless you're single with no significant other, no kids, no hobbies, no recreational interests, and no desire to veg out watching TV or listening to music. You do have some time, and the question at hand is, how do you maximize the use of it?
This series examines just that. We'll look at professional reading, formal education and certifications, and in the later posts, we'll discuss "bootstrap" projects in more detail. I'll have a bit to say about each in this first column of the series.
Let's look at professional reading first. Some of this is naturally dictated by immediate requirements, whether job-related or influenced by your educational plans. This is not what I mean here. What I refer to is keeping up with the IT industry through industry news, short articles, mailing lists and newsgroups...and blogs. For example, I have a constant inflow of mailing list digests...among them The Code Project Insider, TheServerSide.com, the Artima Developer Newsletter and so forth. Each such is profitably digested in 10-30 minutes, depending on my interest level, and may generate a further hour or two of extra reading at another time depending on what interesting articles are linked to.
Of all the newsgroups I am subscribed to, currently six of them are ones I use to see what other developers are talking about. These include comp.lang.c++.moderated, comp.lang.functional, comp.lang.java.programmer, comp.lang.ruby, comp.text.xml, and microsoft.public.dotnet.languages.csharp. Just perusing thread subjects, and scanning a few posts in likely threads, provides a great deal of information for relatively small expenditure of time.
Blogs can be very useful too. I won't really recommend a list of blogs - I find that each developer should seek out and choose their own list, just as with mailing lists and newsgroups.
Stuff like this is excellent for productively consuming 5 minutes, 15 minutes, 30 minutes, or an hour. I've found that for me an hour is sort of the dividing line between passive professional development and active professional development. What I mean by passive is, essentially reading. And active means hands-on: it means coding. If I don't have at least an hour of uninterrupted time set aside I likely won't fire up the development environment and dive into a current project...I'll read instead. That's not to say that you can't fire up an interpretive shell or an IDE and dash out a quick script or tiny program in 10 minutes, just to test out a code snippet, it's just that you doing so is probably in support of something you're reading, rather than being part of a larger coding project.
And read industry news. Mailing lists and blogs will often be your best starting point. Bear in mind, the people that write this stuff are doing a lot of research on your behalf - why waste that resource? You may quite frankly not care much that Microsoft is due to launch three Oslo CTPs in October, but in fact it's a useful thing to sort of know what Oslo is...a few years down the road you may have to know what it is.
What about formal professional development? This may include going back to school full or part time, or attending night classes, or doing home study. You may be angling for a degree, a certificate, or a certification, or just have credentials for having attended a week-long course.
I've had my moments of cynicism about everything ranging from 4-year CS degrees through 2-year IT programs to certifications offered by companies. Fact of the matter is, every one of these things is as useful as the effort you put into it. An MCTS in MS Office Project is as valuable as the amount of dedication the person has to truly learning Project and software project management. So perhaps very few credentials can be dismissed out of hand.
Finally, what do I mean by bootstrap projects? I may think of a better name for these - suggestions are welcome - but essentially I refer to a small set of generic projects, none of them particularly large, that are technology-agnostic. The purpose of such a project is to provide a focus for learning a new group of technologies.
For example, let's consider a personal information manager - a PIM. The generic requirement is simply that the PIM will allow a user to view, retrieve, enter and edit data about contacts, the latter being people and organisations. The conceptual data model is simple - persons/organisations, addresses, phone numbers, email addresses, web addresses, and the relationships between them (1:1, 1:N, and M:N). We don't stipulate at this stage what technology the PIM will use.
The bootstrap PIM consists of the requirement document and the design documents. Once complete it takes relatively effort to keep the requirement document up to date. It should also be possible to keep a small number of sets of high-level design docs up to speed, focusing on perhaps PIM as desktop app, PIM as web app, PIM as web service, PIM clients, and so forth (note that design methodologies evolve - every so often your objective will be to learn something new in this regard; therefore the production of new HLD docs will be your project).
The main idea is this: every so often it'll become clear to you that maybe, just maybe it wouldn't hurt to learn something about Technology Family X. Maybe that's .NET 3.5 with C# or VB, plus Linq, plus Windows Forms or WPF. Maybe you want to come up to speed with Java EE 5 and the latest stuff involved in that. Maybe it's RoR that you'd like to investigate. Or perhaps you want an excuse to improve your C++ so you decide to code up a Linux desktop PIM using C++ and libglade. Just for giggles use a different database for each one.
A well-chosen bootstrap project has longevity. People wanted PIMs in the 1980's, they want them now, and they'll want them in 2050. What they want in a PIM won't even change that much - your requirements and high-level design address those concerns. Actually implementing the PIM in a certain way to keep your skills with specific technologies fresh is the real purpose of the bootstrap. Ideally you'll spend a minimum of time to learn a maximum amount.
In Part II of this series I'll take a look at refreshing of core skills.