His book on Dependency Injection is one of the few recent computer books I had to go through carefully, and with notepad and highlighter in hand. His work on Google Guice is really notable. This ain't just some Microsoft-bound disgruntled guy.

But it's not necessarily surprising. I'm not very familiar with it, but Google's Wave was one of those allegedly killer technologies that just didn't get the corporate support it needed to reach its potential as a disruptive technology. Still, there's a possible tone of sour grapes here. Hard to know.

I'll just say this: I would love to have the privilege to work with someone of his caliber.

In my experience (which is as biased as everyone else here giving advice) your Fortran and COBOL are worthless, if not a little dangerous because the functional programming paradigm runs counter to object oriented programming, Model-View-Controller design patterns, etc. The assembly experience is, on the other hand, valuable because so few of these kids coming into the job market really understand the difference between a stack and a heap, understand what a pointer really is, etc.

In other words, the degree by which your lower-level language experience can give you an inherently deeper understanding of what's going on in higher-level languages may be your saving grace.

If I were to offer a programming language of choice for you, it would actually be Objective-C. (Thus, I would tell you to target iOS for learning your first platform.) It is the simplest superset of C you can find, and it has strong origins to the 1980's, and thus may seem the most familiar/comfortable to you. Given your description of your experience and background, you might be well suited to follow the (free) Stanford iPhone/iPod Touch development course that's available from the "iTunes U" section of the Apple iTunes Music Store. That's an undergrad level course aimed at developing Objective-C and getting started in that environment. And it's FREE.

One last piece of advice to get your head around: make it your mission to write GOOD, ELEGANT code and not prolific code. If I were interviewing you for a job, hearing about hundreds-of-thousands of lines of code would give me the most hesitation. Less is more, and I would want a person who spent 80% of his time thinking about how he was going to solve a problem and 20% of the time doing the implementation. My own experience working with Fortran programmers (in the 90's) was that they rarely understood this, and often wrote GIGO.