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.
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).
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/
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.
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.
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'.
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.
Actually, you could argue that the bank had the resources. It's just that one manager didn't want to share his with other people.
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.
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.)
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.
> 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.
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.
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?
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
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.
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.
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.
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.
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.
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
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.
"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.
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.
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.
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.
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.
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.
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?
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.
* 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.
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.
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.