Live data from Hacker News

An oral history of Bank Python

calpaterson.com

31–40 of 333 posts

Re: An oral history of Bank Python

#31

I was the person who first deployed Python at Goldman Sachs. At the time it was an "unapproved technology" but the partner in charge of my division called me and said (This is literally word for word because partners didn't call me every day so I remember) Err....hi Sean, It's Armen. Uhh.... So I heard you like python.... well if someone was to uhh.... install python on the train... they probably wouldn't be fired. O…

I worked on Quartz for 3 years and loved it. Some devs grumbled about various aspects of it, but I come from an application support background and taught myself python, so I suppose I had fewer developer habits to un-learn.

From what I understand, all this started with SecDB at Goldman, which was a the prototype for all these systems but wasn't Python based. The lore is that SecDB was instrumental in Goldman being able to rapidly figure out what their exposure was during the 2008 crisis.

Some of that team, lead by Kirat Singh went on to start Athena at JP Morgan and then Quartz. I met Kirat once, he was considered a bit of a rock star in the bank tech community. He now runs Beacon, which is basically Bank Python as a service.

Re: An oral history of Bank Python

#32
> In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform. This is a skillset so distinct from that of a normal programmer (let alone a financial modeller) that there is no overlap.

This rang a bell. How did deployment become such an arcane skill?

Re: An oral history of Bank Python

#34
post #11

This immediately sprang out at me: > Investment banks have a one-way approach to open source software: (some of) it can come in, but none of it can go out. I wonder how well this plays with the various open source software licenses?

Most licenses just require your users to have access to the source code. As all the users are bank employees, this is usually easily achieved. If the license is violated it's only by accidental oversight.

Pretty much everything described is a Python library not a change in the Python interpreter so can be under a proprietary license.

The spirit of open source is a different matter.

Re: An oral history of Bank Python

#35
post #9

Sounds like it could be JPM's 'Athena' platform? context: https://www.techrepublic.com/article/jpmorgans-athena-has-35...

Yes, but it is also probably similar to what they have in GS & BAML.

Model seems to originate from GS: https://news.ycombinator.com/item?id=29104401

Re: An oral history of Bank Python

#36
post #4

Doesn't seem that strange compared to K[1] or Q[2], which are used by Wall Street banks. K encourages you to use single-letter variables and bunch your code up as tight as possible into long lines. Here's an example: [3]. Interestingly, their Github repo has some K-inspired C[4], Java[5], C#[6], and Javascript[7]. [1] https://en.wikipedia.org/wiki/K_(programming_language) [2] https://en.wikipedia.org/wiki/Q_(programm…

Very interesting.

I am feeling the urge to learn array processing languages.

There is something very tempting.

Re: An oral history of Bank Python

#37
Title should be ".. of investment bank python", trading and risk has little in common with a retail digital bank like say N26.

The problem with these projects is that the folks leading them have never built a real trading system in entire their lives (the ones who have been there for many years worked with end-of-day batch systems) and there is a layer of useless and incompetent "business analysts" who hide behind their incompetence by finding ways to malign developers..

Pro tip: Dont work for a bank before assessing its open source repos. They have none? Run in the opposite direction.

Re: An oral history of Bank Python

#38
post #32

> In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform. This is a skillset so distinct from that of a normal programmer (let alone a financial modeller) that there is no overlap. This rang a bell. How did deployment become such an arcane skill?

It is not in the value stream.

Our job as sold by the zeitgeist is to write code for features. Fix bugs. And run production.

The logistical part in the middle, how to get the code from commit to prod, is owned by noone and is not considered worth a budget.

There lie the reason we have tools to configure prod, but nearly no tool to deploy code. Even docker and k8s dodge that.

Re: An oral history of Bank Python

#39
post #32

> In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform. This is a skillset so distinct from that of a normal programmer (let alone a financial modeller) that there is no overlap. This rang a bell. How did deployment become such an arcane skill?

There are too many factors here.

One of them is you don't own where your code runs anymore.

This might scare some people until they realize they can get high availability without waiting 3 months for some server to arrive, but it makes deployment harder.

I still believe the main reason people adopt CI/CD today is that "suddenly" deployment in a complex environment becomes easy and software gets tested. A lot.

Re: An oral history of Bank Python

#40
post #32

> In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform. This is a skillset so distinct from that of a normal programmer (let alone a financial modeller) that there is no overlap. This rang a bell. How did deployment become such an arcane skill?

Nahh mate you want to talk to the facilities team, they deal with that sort of stuff.
Post reply on HN