Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hmm, I found the opposite - the fact that there was this global framework that managed all the data and code meant that access control was actually pretty good, better than most tech companies I've worked for. You had a single source of truth for what your access rights were, there was integrated Kerberos any time you needed to access a system outside Minerva. And having all the code in a managed place meant good deprecation cycles - not instant deprecation like the Google monorepo, but tracking and policy for which old versions of libraries were in use and how much that was tolerated. Documentation was at least attempted, and while platform stability/enhancement work did have to be coupled to business initiatives to a certain extent (e.g. "we're doing this performance work to enable us to run risk estimation more often to meet MIFID requirements at low cost") there was leadership that put a value on maintaining high quality code and this paid dividends.


This was 100% my experience too.

The biggest productivity gains were:

- having a single source of truth for both data and code (in a closely coupled environment)

- strong, battle-tested libraries to take care of all infrastructure concerns.

- enforced code dev/test/review/deployment workflows

This let the front-office devs be highly productive on adding real business value for their trading desks.

Remember also that these systems at GS, JPMorgan and BAML started around 2007-2010. The infra we all take for granted today at AWS/GCP/Azure simply did not exist back then, and banks' data security policies at the time did not allow cloud processing.


> Remember also that these systems at GS, JPMorgan and BAML started around 2007-2010.

GS had „these systems“ well before 2000 (via J Aron). I think around the time you mentioned they spread to other firms (in their Python reincarnation).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: