

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

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

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

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

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

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

~~~
gaius
In my experience the users prefer the apps right up until they stop working.
Maybe the developer leaves, maybe the mainstream development organization
changes some other system it relies on, maybe the auditors show up and the
security guys lock down the firewalls and stuff running on a PC under
someone's desk no longer has access. Hell, maybe that PC's hardware fails for
some reason, maybe someone makes a mistake and said developer didn't use the
central, backed-up version control.

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.

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

------
shin_lao
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?

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

------
Patient0
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
Good read, thanks for sharing!

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

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

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

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

~~~
omouse
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

------
andrew1
Hooray for stereotypes!

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

~~~
ig1
Plenty of banks use agile development methodology.

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

~~~
AndrewDucker
Plenty of banks have both.

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.

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

I think Google uses a lot of Java, too.

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

