If I had to advise somebody today I would say learn a field first, and then make sure that you can write the code in that field. That is the best combination.
This approach to resume construction is limited to a (potentially very small) subset of the software development jobs in the market, and is therefore riskier than keeping your general development skills sharp and learning new domains as needed.
Could you first learn the code and then the field? Well sure you can, but business will prefer the other guy first.
This assertion is interesting. I think there's more of a blended balancing of concerns than you're thinking about, and in my experience, knowing how software needs to be developed to work in the real world (whether embedded, desktop, multi-tier, SAAS, whatever) is the really hard stuff to teach, where the relevant business details are usually pretty straightforward. Again, in my experience, being expert in a kind of software is of more importance than the specific domain, though having experience in both aspects of a particular job will obviously be better than being experienced in only one.
In your case (and here's where I think the confusion lies), you're not doing the same variety of "stored data shuffling" that most of the rest of us do, your code is much more analytical and algorithmic. It's quite possible that you're actually doing what a CS degree prepares BSCS graduates to do (extremely unusual in my experience). That means that your "kind of software" is algorithms, so being an expert in that kind of software development IS the more general skill for you. I would personally label that set of skills as distinct from the specific application domain (fixed income, market predictors, risk analysis, etc.).
Further, I absolutely think you're being short-sighted if you're not keeping up to date on other aspects of software development so that if demand for your current skills declines, you can still return to the larger market of software developers. In late 2002, as I was looking for a job in a crap market, I sent applications to both coasts (New York and Los Angeles) feeling that I could interview strongly for jobs in finance or in the various kinds software being developed in LA. I got offers from both coasts and I'd like to think that it was because I successfully argued that my fundamentals were strong and I could quickly get up to speed on anything that was missing.
I have no idea what's behind Siebel's statements. In my continuing experience as a software developer and as someone who's hired software developers, he's completely full of it. I suspect that, like many others who hire software developers, he's frustrated by the price he has to pay for highly skilled people (the 10x developers) and he's just venting. He's entitled to do that, of course. I'm just as entitled to ignore him.
After all most of the code these days is written in "very safe" languages where it is hard to shoot yourself in the foot.
Out of curiosity, which languages are these? I've been writing commercial software for 15 years. I try to learn a new language each year (ruby in 2006, php in 2008, python in 2009). But I currently have very little idea what "more safe" or "less safe" mean when describing a computer language. Any pointers?