models are optional or as indispensible as trade capture@@

(A blog post. No need to reply)
Trade booking is the most essential component of any trading system. If a small trader has no computer system, he would make do with a poor man’s trade booking tool like Excel or physical paper to record the trades he did and the positions he holds.

Now compare quant models. I feel models are optional. It depends on the asset class spectrum. On one extreme end are listed equity options. The other extreme might be vanilla government bonds.

Vanilla Government bonds (not futures/options) involve no option-pricing, and are risk-free (notwithstanding the recent Greek/Irish defaults). I would assume there’s no need for quantitative model in pricing/risk systems.

Treasury futures is a different story. There are models to predict price distribution of underlying asset. Since the price is in the future, there are probabilities to work out — a branch of statistical mathematics.

Muni cash bonds need some model? not much. There’s perhaps some credit risk mathematics. The models generate a bid/offer price pair for each bond (based on the position held by the trader), but a trader offering the same bond can choose to use that price (plus a spread) or ignore it. It’s optional to a lot of muni traders.

On the extreme end of the spectrum, listed equity options are priced and quoted on exchanges using widely agreed models (lognormal stuff). Are models necessary to a trader in this market? Can an investor simply follow her instinct to decide for herself a bid/offer price?

transform/copy with push_back on yourself (i.e. a container)

    // abbreviations is a container.
    transform(abbreviations.begin(), abbreviations.end(),
        back_inserter(abbreviations), suffixAdder(c));

Broken, because abbreviations.end() dereferences to a special sentinel “value”. When you push_back on abbreviations, that sentinel “value” shifts to the right.

For example, If initially end() points past the 5th and last node, then after 1st push_back, the 6th position is populated, and the sentinel “item” is now after the 6th node. Initially you wanted to call insert() (and suffixAdder()) 5 times, but now you need to call it 6 times! In fact, it's a infinite loop as we keep shifting the finishing line.

Solution — use front_inserter instead of back_inserter.

c++ private subclass to increase visibility@inherited member

class X : private B {
  public:    B::c;      // c was private, now is public
void someFunc(X x){
All my c++ books fail to mention this C++ language feature[1]! The above c++ code (miraculously) works but took me 20 minutes of search —

Both sites explain the rationale —
* private subclass X inherit as private all of parent’s Public members like B::c2. Therefore if main() has a subclass instance, main() can’t access the now-private field
* This language feature allows the subclass to increase accessibility of the inherited member.

[1] I guess this feature is seldom used, but it’s tested in IKM.

GS workload — squeeze-in

Here's another reason GS developers get _2_to_3_ times the work done per man-month compared to other companies on Wall Street.

Say at beginning of Jan I start a 4-week project in GS. Need to release by end of month. Then scope expands by 30% — fine we can absorb it in the same timeframe. Then some unrelated production issue pops up. No one else knows it better, so I let it squeeze into my workload. It is taking many hours, but manager won't extend the deadline. Then other mini-projects squeeze into my workload. I end up spending only half my time on the main project. However, deadline stays the same. I'm now expected to double up my effort to swallow all the new stuff squeezed in.

You may think it's unreasonable, but the hard, cold fact is, the other team members could cope, so must I too. Sometimes they look just like sponge with unlimited absorption.

Mind you, the initial 4-week estimate is not fake — It's a reasonable estimate by all accounts. But GS managers know they can squeeze in more stuff later, so they do.

technically challenging role on the WS job market

Imagine a tech lead role that requires substantial architecture + implementation capabilities.

Q1: are there such roles on the market?
A1: yes I have seen some people playing such roles.

In our discussion, we often say “this job spec seems to be tough, but once hired, just about anyone can do the job.” or “Other people in the team are probably mediocre so the new hire need not be as good as the job spec says.”

In SG, a trading sys developer is paid higher than an Oracle DBA, or a manager at HP, or a system architect at some government companies (I know such friends), so it’s easy to think that trading dev skill set requirement must be significantly higher than the average java developer. But I believe just about any smart java developer can do the job.

Now back to my answer A1 above. Some positions on the market are indeed that challenging. How do we tell which one is? If I know which one is, I could either avoid such a “hot” job, or grab such a “hot” job.

who to command a trading IT team

Among these 4 alternatives below, which one can best command a typical fast-paced, elite trading engine developer team?

Assumption – battle-tested trading system architects are rare, therefore in some cases, manager must select someone slightly less qualified. Needless to say, in reality one person often wears multiple hats.

– BA? Personally I feel No but not sure in practice. Good local domain knowledge, business communications … is half the story. However, some BA’s have recent development experience.
– PM? Often less technical and less hands-on. Perhaps insufficient. Many practical problems require implementation insight
– Architect-on-paper? Must become hands-on to command. Too many uncertainties on the ground. You must be ready to roll up your sleeves. Planning vs execution — The latter dominates.
– Lead developer without architect credentials? Usually good enough. Practical problem solving. I’m biased towards the hands-on developers.

Now for my long term survival to age 65, I feel the hands-on developer enjoys more flexibility and career choices. More geographical choices too.