Want to be a programmer in an investment bank?
sapessi.com
sapessi.com
Our development cycle is super fast, yet I work on very sensitive applications and infrastructure (real time trading, pricing, risk etc).
Bottom line: Jobs vary significantly in any industry and within any firm.
Oh, and for goodness sake don't put down on your cv that you've read the first 13 chapters of Hull and know Ito's Lemma and the Black Scholes model. (Unless you just want to give people a good chuckle.)
If you really want to bone up on your financial maths with a bias towards a job in computational finance I always recommend people read Joshi. http://www.markjoshi.com/
I threw together a system with Apache and Perl (it was the late 90s) for traders to monitor their positions and that we used to run risk analysis on a daily basis. The traders preferred my hacked together system to the official one from the IT department, because it was easier to use.
We wrote a lot of VB apps, because that was what my boss was comfortable with. Not the greatest development environment, but at least I could just write code that my boss and the traders actually needed to do their jobs, without worrying about internal politics and bureaucracy. I would say that's a lot more important than choice of technology stack.
A manager did not want to give the IT department the resources they needed to develop this new app, so he got a coder to hack together a solution which is probably unmaintainable and which they will eventually inherit anyway. The fact that you mentioned VB makes the story even funnier to me, because my department was frequently the victim of a code-and-run accountant who wrote awful Access apps (it's the worst code and data modeling I ever saw). Inevitably, the day comes when these apps have to be integrated with the rest of the infrastructure or the original coder doesn't want to deal with his mess.
An IT department exists to satisfy the company's needs, not vice versa. If you can't do the job with the 'resources' given to you, resignation is always an option. But don't fail to do your job and then whine about 'resources'.
People liked and used these apps a lot at my bank too. And that's what made the problem worse. The apps didn't scale, the data was inconsistent or simply not structured (so it was hard to pump it into the main database) and the code was terrible, so it was very hard to add new features.
These things work well for a while (not much data, few users), but when the going gets tough, IT pays the price.
Then the users come to IS and piss and whine but get nothing but blank stares in return. And you know, stuff IS does takes time, because we build it to be supportable for the next decade or two (yes really). We write a runbook so someone who's never seen it before can recover it if it fails at 3am, and we make sure it's monitored. We get it signed off by compliance for regulatory oversight. We penetration test it. We back it up offsite and replicate it to the DR site. We stick a generator behind it and we know how many Watts of power it needs (we even know what it weighs so we don't overload the floor in the datacentre). We take its dependencies into account when doing any other work.
Basically, we act like grown-ups with other people's money, something they've largely forgotten in the front office.
My boss was the kind of guy who wrote the kind of code you are talking about. In fact, he would tell me to not waste time making the code "pretty," just get things done quickly. I simply ignored him, and wrote clean, well designed code anyway. :)
I always write in the most productive language I can, given the choice. But it is still possible to design and structure your code well in even the worst languages.
I understand the concerns IT has about "cowboy coders." But we're talking about people who didn't even understand the relative precedence of addition and multiplication, in this case. So this was more than just wanting to by pass bureaucracy, I'm honestly not sure whether they were capable of implementing the mathematical models my boss wanted. (Not that I was a math genius, but I had mostly mastered operator precedence.)
Needless to say I didn't take the job - and I still know some of my peers who went that route. Thankfully none of them really liked programming anyways, and the paycheque sort of numbs the skullcrushing tedium of it all.
I think the lesson here is less "don't work for banks", and more "don't work for a company that doesn't value technology". You will get this same crap at, say, a factory (been there done that)... a lot of really bad code written by really incompetent people, mostly because skilled programmers would never voluntarily subject themselves to that sort of environment.
Seriously, what's the point of such posts? You take from two and three experiences and extrapolate to a whole industry?
If one were to be cynical, we could say that PG's essays about startups, pre-YC, were based on exactly one experience. And yet, they still are very well written and contain good advice. Of course, it's necessary to be up-front about the fact that it's an anecdote rather than some kind of broad survey.
By the way, I did c++ for most of those ten years, and my team (very small) was the only c++ in the sea of thousands and thousands of programmers.
And they did have a grid effort (which produced a particular astonishing very positive result), all written in c#. But again that was a very small team.
Shame.
I do feel that a lot of the points are somewhat valid, though, and because it might act as a catalyst for some interesting discussion on HN, I upvoted it anyway.
Another point to note is that Investment banks are very heavy users of technology and have varied needs , a FX trading platform has different requirements versus an online sales portal. You will invariably find all kinds of technologies being used.
Large investment banks (like any large company) have many different needs for software, and each of those have their own priorities.
That being said, we have a sizable J2EE team as well.
Good engineers & Good management => Good results
Bad engineers | Bad management => Bad results
Language X | Framework Y => See above
Anyone who believes anything else should either come out of college or go back to it.
Having spent 4 years building software at large investment banks, both on the coding side and on the managing side, I can affirm without hesitation that the glacial pace has very little effect on the (high) incidence of bugs. The quality of software produced in banks is generally appalling.
The reason it's slow is because the complexity is sometimes very high, the volumes of data to process are often very large, and the communications overheads between bank departments are just insane. Quality (or lack thereof) has nothing to do with it.
I work for a company that handles a lot of commerce, and bugs can be disastrous, and stakes are high - we still iterate. Sure, we're not pushing new versions live every single night, but our cycles are still relatively quick.
I think the "there's too much on the line if a mistake happens" line of thinking is a cop-out. There are ways to mitigate this risk, safeguards and methodologies.
That's the advantage of n-tier systems. You keep your ancient databases, stick some business rules on top in Java and then talk to them from a bunch of clients that you can tweak as much as you like without worrying that you're going to break the important stuff.
* No agile method stops you from doing a bit of design thinking before you code, when it is needed. Agile is against Big Design Up Front as a matter of course because it so often fails to be good design, or appropriate for what the business ends up wanting.
* Lots of automated tests done while coding that allows you to think sooner and better about your code. decreasing the need for big design up front, and better suiting the design to what you actually find your needs to be. Not thinking beforehand is a risk for sure, but producing a big, inflexible, unsuitable design is another risk. I've seen it, you may have too. Thinking without testing the thoughts in code is bad too.
* "Tests after the fact" refers to QA. Agile also emphasises unit tests before and during the fact. "Tests after the fact don't do enough to lower the number of bugs" is something that any agilist would agree with, but would recognise as an argument for agile.
* Rapid release to QA allows actual users/sysops to see where you're going much earlier, hence mitigating major risk of building the wrong thing/right thing but not scalable/performant enough/etc.
Anytime you are directly working with Traders or Front-Office Quants this is simply not true.
The big problem with a system like this is that, when faced with the do-it-right/do-it-fast dilemma, do-it-fast is what wins. Too much of this can yield a brittle system as hacks pile on top of each other, so it helps to be able to slide 'proper' fixes into the trailing dev/test cycles. A flexible platform/language helps, too.
I think Google uses a lot of Java, too.
They think their code is a safe investment. Why? Because they are still believed in that slogan - "code once run everywhere" which was actively used by IBM and Sun to sell their hi-end hardware. Second they think their code is cheap to maintain and extend because there are a vast crowd of J2EE developers, especially in developing countries. And, yes, off-shoring. It is so good to "save" budgets. Together that is why. Java is backed by so many big companies because it is the cheapest way of off-shore development (coding fabs).
And of course, project managers and IT executives in an investment banks does not want to create another facebook. They want their paychecks and bonuses and paybacks from their offshore partners.