Most of my developer friends (mostly senior developers) in Goldman and Baml shun the in-house frameworks (SecDB or Quartz). Key reason cited is skill mobility and market value. There are other reasons unmentioned. Indeed, we have to spend many late hours learning the idiosyncrasies of the framework, but that value…
(Quartz position is predominantly programming) Someone said if you stay outside mainstream programming technology like java/c#/c++ for a few years (like 3Y) then you will forget most of the details and have a hard time on the job market — 1) getting shortlisted or 2) passing the tech screening.
I thought I could learn some serious python programming but left disappointed. I didn’t use a lot of python constructs, python hacks, python best practices, python modules (there were so many). I don’t have a good explanation — I feel most of the technical issues we faced were Quartz-specific issues like DAG, Sandra …. For an analogy, I can give you a 3Y job to develop c++ instrument drivers but restrict you to my framework “CVI” so you are shielded from basic pointers, smart pointers, STL, threading, virtual functions, Boost, the big 3 (copy ctor, assignment operator, dtor) or any of the c++11 features. Over 3 years you would learn close to nothing about c++, though you would learn a great deal about CVI (C for Virtual Instrumentation, used in my early jobs.) So over 9 months I didn’t go up a rewarding learning curve in Python and emerge a “grown-up” developer in python.
Besides, I hoped to learn some financial analytics, pricing, risk, stress test, back test, linear algebra, matrix operation, curve fitting, etc. Not much. Would a longer stay help? Maybe, but I doubt it.
It’s true that many Quartz projects give you more direct exposure to “domain knowledge”, since most of the low-level nuts and bolts are taken care of by the Quartz framework. In my projects we worked directly with trades, live rates, accounts, PnL, PV, risk sensitivity numbers, curves, risk buckets, carry costs, and (a large variety of) real securities, …
However, there was no chance to work on the quant library as those modules belong to other teams in a well-organized dev organization like Quartz.
Resolving technical problems is always frustrating (until you have 3 years experience in Quartz) because the knowledge is kept in people’s heads, so you can’t google it. The documentation appears extensive, but actually very very limited compared to the technical resources on Python or any popular language.
Quartz has good dev practices like automated build/release, test coverage, code reviews, so you might benefit by learning these best practices.
Database technology is an essential skill. If you like object-oriented DB, then Quartz gives you the exposure, though the valuable skill of developing an OODB is reserved by the early pioneers of Quartz. In my opinion, relation db RDBMS) is more widely used then OODB, so it’s more valuable to learn how to write complex SQL queries and tune them.
Quartz offers elaborate event subscription, so changes (on market prices or positions or user input or configuration) propagate throughout the OODB fabric in real time. I think this is one of the sexy (and powerful, valuable, enabling) features so I was excited initially. But it’s too complex too big. I used this feature extensively but didn’t learn enough to benefit. Analogy — you can learn many Korean words but still not enough to converse, let alone using it effectively to communicate.