Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An oral history of Bank Python

calpaterson.com

Post reply on HN
Print view View original

301–310 of 333 posts

Re: An oral history of Bank Python

#301

Post by 3maj »

grvdrm wrote: post #109

I'm curious about experiences in other similar orgs: I work as a portfolio manager for a large reinsurance/insurance company but spend significant time in SQL, Python, Excel (not unexpected I'm sure). The Wapole platform in the article struck a chord with me. We built something roughly similar - call it Trek - that handles jobs. Jobs encompass lots of tasks - reading/writing from Excel, executing SQL, running Python,…

I work in a Technical PM role at a large North American Insurance company and used to work at one of the largest Banks as a Sr. Business Analyst (or Sr.Systems Analyst depending where you are).

>lots of our software devs write bad code

Ultimately, you get what you pay for, all our full stack devs are making 6 figures... While it might not be FAANG money they also almost never work overtime and the stress levels are relatively low.

>Are these folks embedded in the business? No, thats my job. As a Tech PM I'm supposed to know exactly the business requirements, what my guys can do (to manage expectations) and any limitations of the software/business. I find the best PM's are the ones that have some Dev experience but also have extensive people skills and understand how to manage stakeholders.

>are there folks using the more technical bits of the systems that are business-oriented? It varies, I started off as that business-oriented person (corporate finance) and eventually made my way over to the Data side of things and finally some programming work and now I'm running projects. While you won't get many analysts/portfolio managers doing dev work I do try and get them to have a hands on approach especially when doing QA and UAT work.

Re: An oral history of Bank Python

#302

Post by hnfong »

throwawaygh wrote: post #147
kwertyoowiyop wrote: post #106

Earlier quoted context omitted.

For some reason people think everything is as good as it can be at FAANG and other big name tech companies, and everyone else just walks around with their pants down at their ankles bumping into walls until 5:00. It’s just not true.

I mean, it's not just FAANG. Literally everyone except banks use the standard Python environment. simonh is right about the reason for the forked tech stack. Actually, it's probably not FAANG folks at all. I'd expect ex-FAANG folks to be more sympathetic to the forked python situation... FAANGs have an abundance of non-standard and frustrating infra (wasn't 5TB just posted yesterday?), and maybe even on steroids comp…

Exactly.

Facebook literally maintains a python fork: https://github.com/facebookincubator/cinder

Google invented "NoSQL" before anyone else knew what it was, and all those "cloud" tools they used internally were obviously proprietary (except the ones they open sourced). Ex-Googlers I work with typically had to spend quite a bit of time re-adjusting to the "inferior" tools and processes in other companies.

Microsoft invented their own development ecosystem, and the only reason it's "common" or "standard" in the tech community is because they sell it as a product. This is the same for Apple at least for iOS development, and Amazon for their cloud service offerings.

When companies have millions of dollars to spend on maintaining a custom development environment that they think will give them a competitive edge, they will do it. It's the smaller shops that can't afford not to go with the flow, so to speak.

Re: An oral history of Bank Python

#303

Post by 3maj »

grvdrm wrote: post #117
klelatti wrote: post #110

Earlier quoted context omitted.

Really interesting comments. I'd guess that you have proprietary (e.g. valuation / capital calculation) systems that need to interface with Trek in some way. Could you share how you've approached that at all? Also not clear why R couldn't be added to Trek alongside Python and C#?

Certainly - let me try to share succinct version germane to my day-to-day - We regularly perform group/segment level risk roll-ups. Involves running computationally expensive (by insurance standards) in-house and third-party models that estimate loss from hurricanes, earthquakes, etc. A lot of our insurance data is unsurprisingly stored in disparate systems that don't talk to each other, and in some cases, don't have…

>read CSV file from another third-party Generally, if you're getting a CSV file from a client that indicates to me that theres a good chance they're exporting info from their systems and sending you the CSV.

Have you considered developing a client facing API that can be used to send and digest data?

Re: An oral history of Bank Python

#304

Post by bantatoes »

harel wrote: post #44

I worked on Quartz for a while as a contractor. Hated every second of it. Python version was old (2.4 if I remember correctly when 3.x was already the popular version). But that wasn't it. It was the proprietary version of everything in the stack that got me. Proprietary ide, source control, libs etc. I noted that none of the others who have been there for years have any transferable skills that can cary them out of…

I think this would have depended on the teams/individuals you worked with. I recall some devs being completely clueless about environments - my code (that depends on dozens of other files) in uat is producing different outputs compared to my code in dev, why? Some didn't know how to debug. Many went on to FAANG as senior engineers (including Uber when it was the next big thing), hedge funds (citadel, 2s), startups (twilio, is twitter still a startup?). And as far as python knowledge is concerned - I recall attending a number of python talks given by my former colleagues at Python conferences, various PEP discussions around whether a given PEP would help or be detrimental to qz. As a matter of fact one of the qz core engineers is now also a PSF core engineer. Quartz was polarizing, but there was/is plenty of talent among the engineers. P.S.: fwiw, when I left baml, the migration to 3.6 was nearing completion, and the migration to 3.7 was in progress. I guess at some point we realized python and qz were not going away, we must to migrate, so infra was built out to make future migrations easier.

Re: An oral history of Bank Python

#305

Post by 0xbadcafebee »

Before Open Source, you hired a company that "did" software/computers. You knew jack shit about it and couldn't do anything about it other than "run commands".

After Open Source, you still did that, but you also occasionally hired people to download and cobble stuff together to save money, and maybe one or two people to write code to help cobble together stuff.

Over time this evolved into managing entire "technology divisions" of people writing code and cobbling together stuff, to manage larger and larger internal projects, to support teams, to build components, to eventually be used by one internal product used by a customer. 50 different teams to build components, and 1 team actually servicing a customer. And each component built is exactly the same as components built at other companies. Sometimes even exactly the same as other components in the same company.

Nowadays a Big Bank might produce more software than Facebook, and none of it ever escapes into the world as Open Source. Whole oceans of software are birthed, live and die in the shadows. Millions of lines of code that live for half a decade. Constantly manufacturing their own hammers because they believe theirs will work better than an existing hammer, or because they're too lazy to learn how to use an existing hammer. And never sharing their custom-built hammers with the rest of the world. All because some clueless executives believe this solves their business case better than buying something off the shelf and making it work for their business case.

Re: An oral history of Bank Python

#306

Post by mst »

lmm wrote: post #282
mst wrote: post #259

Earlier quoted context omitted.

People who make complaints like that are privileging their own personal aesthetics over pragmatism. Same mistake as the people who keep talking about perl being "dead" while they're deploying their production platforms on debian or red hat based systems and ignoring the fact that the packaging and release QA work for those distros is substantially dependent on - actively maintained by the distros in question - perl p…

Sounds like someone else is putting their personal aesthetics over pragmatism. Perl is a dead language walking, the fact that there are some tools it hasn't been worth rewriting doesn't contradict that.

I'm talking about actively chosen new development because it's still the dynamic language most oriented towards being comfortable as part of a unix environment rather than simply running on top of one.

Modern async/await + heavily OO based perl is not, I suspect, the language that you're thinking of when you made your comment.

Re: An oral history of Bank Python

#308

Post by Sunspark »

dustintrex wrote: post #270
Sunspark wrote: post #266

Earlier quoted context omitted.

It's a bank, so probably his reward for good performance was 10k at Christmas.

You may have dropped a couple of zeroes there.

Maybe that bank is more generous. The one I worked at begrudgingly counted out the pennies like it was coming out of the war orphans fund or something.

Re: An oral history of Bank Python

#309

Post by mleonhard »

Maven911 wrote: post #271
seanhunter wrote: post #76

Earlier quoted context omitted.

I know Kirat really well. Fun fact, one two-week dev cycle we had 667 distinct developers commit to the secdb code base which Kirat's boss described to me as "The number of the beast.... plus Kirat" Second fun thing. Kirat was advocating for lisp for secdb for a long time and used to rag on me for liking python when it's so slow.

It's amazing how a few people have left such a big mark on a part of the investment banking industry. I missed Kirat right before exiting BAML but met all his "disciples" and Dubno..including his miniature dinosaur and telescope in his office :). Very much felt like tech religion where no open debate on merits and drawbacks could be discussed. And a lot has changed in terms of engineering innovation with turnover sin…

Why is the number of people who "left a big mark" so small?

1. An organization/industry can adopt each new technology only once. New technologies arise infrequently. Each time they arise, only a few people get to work on the projects introducing them. In other words, opportunities to leave a big mark are limited.

2. Credit for innovation is political capital. People hoard political capital and become powerful. They act as gatekeepers of innovation and take the credit for successful projects.

Re: An oral history of Bank Python

#310

Post by seanhunter »

Atothe4 wrote: post #298
seanhunter wrote: post #292

Earlier quoted context omitted.

Hehe. Well I guess you would have a unique insight into his thought process. ;-) But yes indeed that's certainly another explanation and it did indeed work that way.

Air cover is crucial, but you can't take land without good boots on the ground ;)

Well thanks for the air cover, and for all the other opportunities you provided for me and others at GS. I really appreciate it. It was an amazing time and I learned a great deal.
Post reply on HN