What I've discovered is this: In larger organizations, you get respect by being the "answer" guy. If everyone's coming to you for advice, you become more important.
In small organizations, you get respect for being the hero, who waves his magic wand and fixes things after everything goes to shit. This is easy to do since most of the operations are pretty basic and cowboy to begin with.
The biggest key to respect (in mid-to-large organizations) is playing the political game. The more your name is on peoples' lips, the more important you'll appear to be.
But the question is: WHY do you want it? If it's for the money, you can get much more money with less effort freelancing or consulting. If it's for security, you could also get that by digging yourself so deeply into an essential project that nobody can get you out. If it's for the admiration of your peers, just remember that it also sparks envy, and separates you from them emotionally. If you wish to belong, you're far better off choosing a faction to ally yourself with, and remaining loyal. Elevation is a loner's game.
My advice: Just pick something interesting and go with it. If it doesn't work out, pick something else. Fear of failure is worst in people who haven't failed yet, and that fear will impede you far more than actual failure ever could (I've had a few spectacular failures in my lifetime, to the point of being reduced to the clothes on my back, and each failure made me more fearless).
You don't need the respect of others when you're making your own path.
Quant-Developer is a weighted sum of q% quant and d% developer. Ideally you'd like q to be high and d to be small. What happens in practice is that many companies will hire a quant developer, throw 90% of d at you and keep you enticed with some 10% q. This is rather sad, but I have seen this happen to more than half of the graduating class of 2011. Perhaps 5% of my classmates are doing 100% q. Another 20%, including myself, are remarkably lucky to be doing 80%q , 20%d. But the rest of my classmates are stuck with 80%d 20%q, and even the q is watered down cookbook solutions. And this is the case with University of Chicago graduates, so you can imagine what goes on with grads of non-top-10 quant schools. There are companies in the chicago area (morningstar, for eg., and even much of cme) which advertise for quant developers but give you 99%d, 1%q ! What they really want is an sql guy who maintains the securities database and writes stored procedures, but they will go ahead and call you "quant developer" anyways. Its a rather shady practice imo. Sadly, the worst offenders are startups in finance. I spoke to one who asked me a ton of interesting quanty questions straight out of Mark Joshi...but when it came to the actual job I'd be doing, the CTO says (actual quote) "you don't need anything more than mean and variance, we are all generalists here". Then why do you want a guy with a math masters and a cs masters and a quant masters...just hire a high school student.
Your best bet is to stick with IBs & large banks. They have tons of really interesting ( and really hard ) math problems to work on, they aren't going away anytime soon,and they will pick up the tab for your math phd costs ( or lightweight garbage like series 7 and cfa, if pde ain't your thing).
I did this a few years ago and love it.
Things you should know depending on what you're doing: Math/Finance - statistics, know stats inside and out. - differential calc and finite difference methods - Black Scholes,
Programming - the R langugage - vba, if you don't know R really well then vba can be useful for modelling. VBA is approachable enough that every trader uses it and when they move shops they take their vba models with them. - C++ or C, it's still used very widely and often is the language that interviews are conducted on. - TCP/IP performance. - linux kernel tweeks for performance.
Currently I am reading these books:
Mark Joshi: The Concepts and Practice of Mathematical Finance
Daniel Duffy: Introduction to C++ for Financial Engineers (I already know C++, but I read this because of the finance related stuff.)
b) By switching professions to a more "respected/cool" one do you not think you're just contributing to the problem of programmers not being taken seriously?
By using "cool", I get the impression that you're thinking more about respect from people outside work, rather than those you are working with. I think the article was talking about respect from the people you work with and work under, in the sense that if you are not respected, then you likely won't get paid what you are worth. From the point of view, point (a) is a contradiction - if you are not respected by the company you work for, the pay won't be good.
Exhibit: The "starving artist" vs the "slimeball lawyer".
" contributing to the problem of programmers not being taken seriously" I don't know. Maybe switching professions is an extreme thing, but gaining some knowledge in a specific domain (other than programming) is a good advice to every programmer.
As for working in other fields, from my experience in a biology lab, yes, you may earn "God-like" status sometimes, that is, become the last resort for everyone, but truth-be-told, sometimes you find yourself doing boilerplate work by just implementing some algorithm and nothing too exciting.
Yesterday i received an official invitation from the city council to a banquet for entrepreneurs in our city...
Some people argue that IT provides efficiency and in some cases increase revenues as well. The hard cold truth is this:
1) It's hard to measure $$$ from IT projects
2) It becomes internal politics: it shifts the balance and nobody wants IT to have more power.
- Even if am not the quickest/best at it.