Want to be a programmer in an investment bank?

http://sapessi.com/2009/11/want-to-be-a-programmer-in-an-investment-bank/

by sapessi • 17 years ago

59 43 17 years ago

andrew1• 17 years ago

Hooray for stereotypes!

ivenkys2• 17 years ago

That's a lot of oversimplification. Yes, there are niches in banks that would probably fit that profile but then do so many other companies.

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.

potatolicious2• 17 years ago

I was once offered a tidy sum to work in New York, cranking out desktop C# applications for large banks. My interviewer was a nice guy, and told me straight up that I should expect very little real code, and more taking a beating from traders on why their green button isn't green enough, and how it's a little too far to the left.

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.

nzmsv• 17 years ago

Developing bank software is just different. There can be no rapid iteration, because every bug is disastrous. As a result, software evolves at a glacial pace. I'd think that the answer to the question about what technologies you need to know to work on financial systems would include COBOL, possibly before Java.

swombat2• 17 years ago

There can be no rapid iteration, because every bug is disastrous. As a result, software evolves at a glacial pace.

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.

potatolicious2• 17 years ago

"There can be no rapid iteration, because every bug is disastrous"

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.

ig1• 17 years ago

Plenty of banks use agile development methodology.

gaius4• 17 years ago

Plenty of banks also haven't touched code that's been running just fine for the last 30 years. You just upgrade the mainframe under it...

StrawberryFrog3• 17 years ago

Plenty of banks want to use agile, because they've heard it's cool, is said to deliver more better software faster, and is attractive to good coder job candidates. How far they are actually getting with it is another question.

StrawberryFrog3• 17 years ago

er, getting bugs out early is a major argument in favour of test-first agile iterative methods. You don't ship every iteration, but give it to the testing team. Would you get better results from giving your testing team a new release once per year?

omouse2• 17 years ago

Getting bugs out early is actually a major argument in favour of thinking before banging out code. Tests after the fact don't do enough to lower the number of bugs there are.

ivenkys2• 17 years ago

I disagree with this. Again, it depends on the area you are working in - software does not evolve glacially on a Trading Platform. Its in fact quite the opposite.

Anytime you are directly working with Traders or Front-Office Quants this is simply not true.

dannywoodz2• 17 years ago

Agreed. The system I worked on had scheduled releases every two weeks, with a smattering of emergency releases in between. In some cases, simply being able to reliably price a given trade put you ahead of the competition, particularly in the exotics space, and could make or break a deal.

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.

swombat2• 17 years ago

What a ranting post! Especially when attacking such an easy target, where there are so many good points to be made, it's sad to see this poorly structured, badly phrased "let's just get it off my chest" rant in place of a good, solid post.

Shame.

haasted• 17 years ago

I agree with your take on the nature of the post, its points could easily have been presented more elegantly!

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.

Tichy• 17 years ago

A lot of younger people fancy Java, too. Not saying that is a good thing.

I think Google uses a lot of Java, too.

jimbokun2• 17 years ago

In my one job working for a bank, I was hired directly by the head of market risk management. He hired me because he wanted a programmer who would just do what he asked instead of having to negotiate the internal IT bureaucracy.

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.

forinti2• 17 years ago

I once worked for a bank will now tell this story from the IT department's point of view.

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.

seunpy• 17 years ago

You missed the part where the users preferred the OP's apps.

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'.

jimbokun2• 17 years ago

Believe me, VB was not my choice. :)

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.)

shin_lao2• 17 years ago

Curious then, I was certain I spent the last 2 years building a grid computing system for an investment bank using modern C++... Must be me.

Seriously, what's the point of such posts? You take from two and three experiences and extrapolate to a whole industry?

davidw• 17 years ago

> 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.

shin_lao2• 17 years ago

I think PG's essays come with an implicit "this is my point of view through the prism of my experience" disclaimer.

wglb2• 17 years ago

I think that there is truth in this posting, having been at a large insurance company for 10 years. Some of what he is saying may be particular to banks, but there is an "enterprise" software mindset that his description is a fair representation of, for large commercial financial outfits.

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.

prodigal_erik• 17 years ago

Never worked in banking, but I'm having trouble imagining that. Are the bankers aware how often the phrase "undefined behavior" appears in the C++ standard? Do they have formal verification tools, like I used to hear rumblings about Ada? Or just a crazy high qa/dev ratio?

ramchip• 17 years ago

C++ isn't an easy language, but it's not that hard. Using a reasonable coding style it's possible to make very solid applications.

gaius4• 17 years ago

Are you aware of how often "undefined behavior" happens on the trading floor? :-P

dannywoodz2• 17 years ago

I spent four years writing Smalltalk (VisualWorks and GemStone) at an investment bank, and didn't look at a line of Java the whole time I was there. We were a wart on the architecture board's bum, not fitting into their Grand Unified Vision of Approved Java Technologies, but the system was--and still is--the only platform capable of pricing and risk managing some very oddly shaped (and therefore very high-margin) trades. It was also good fun to work on.

elecengin• 17 years ago

I work in finance as a developer, and I have found there is also a demand for high performance C++/C software people - our development team is composed mostly of ex-telecom engineers from Cisco et al. The performance is a priority when trading latencies are involved.

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.

huntse2• 17 years ago

So I have a really interesting job in the front office at a real investment bank. I have worked here for several years and have used (among others) perl, python and C++. I have touched precisely 3 lines of java in all my time here.

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.

wglb2• 17 years ago

Is your bank one of the larger ones, or smaller? I am wondering if that has an influence.

gaius4• 17 years ago

Not really. A bank is more like Ancient Greece, squabbling, semi-independent fiefdoms that only look united from the outside. Two groups in the same bank can be like night and day culturally. The biggest factor is the personality of whoever's the head trader (that week).

huntse2• 17 years ago

Larger and more profitable. The sort of things that will get your cv noticed by the right people around here are: Haskell, some sort of particle physics or similar simulation experience, and/or games programming experience.

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/

Patient0• 17 years ago

For a good counter counter example to this guy's rant: Functional Payout Framework used for exotic options pricing at Barclays Capital, developed entirely in Haskell: http://www.lexifi.com/downloads/frankau.pdf

alexkay• 17 years ago

Good read, thanks for sharing!

tybris• 17 years ago

It's very simple:

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.

omouse2• 17 years ago

Substitute "engineer" with "computer programmer" or "software developer" and you may have a point. Also, you can use the words "and" and "or". V and ^ if you prefer mathematical symbols

c00p3r• 17 years ago

Yes. J2EE is the de-facto standard for in-house development and there is some reasons behind.

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.

Want to be a programmer in an investment bank?

Related Stories