exposure: semi-automatic(shallow)Accu #$valuable contexx

Opening eg — In RTS team, granted I didn’t get deep[2] socket experience or latency /engineering/ experience, but over the years semi-automatically I would get some valuable exposures, by raising good questions about .. sockets; reliable orderbook replication; error recovery; throughput engineering…

eg — in mvea team, I can get some valuable exposures to FIX; large scale and reliable equity OMS; low-latency (caching); order routing; automatic hedging; partial fills; limit orders; order cancels/amends; busts… Even if I don’t get deep experience on this job, my resume could claim genuine experience! Strategic positioning … (shallow) Accumulation

eg — in citi-muni, I got exposure to mkt-making; event-driven limit order repricing; PnL roll-up; mark-to-market; swing; JMS; Gemfire…

Key points about the “pattern”:

  • thanks to the strategic contexx, you get to accumulate (semi)automatically
  • robust commercial value in the skill
  • shallow [2] accumulation — I call it “exposure”, enough to impress some interviewers.
  • [1] small amount of effort — much lower than GTD, getting a job/certificate, losing weight
  • consistent effort ..

However, as the years go by, many developers stop digging with questions and others ignore the opportunities to dig into the difficult codebase because … they don’t have to:(. The automatic learning is a valuable option if you put in some legwork [1]. In contrast, some jobs don’t offer much automatic learning —

  • OC team: not so mainstream. I could still learn some WCF; reliable windows servers;
  • Qz team: poor portability. I could still learn some curve building; ticking risk;

[2] In contrast, here are examples of “deep” experience —

  1. from-scratch (95G) wait/notify solution
  2. from-scratch (95G) sybase stored proc to manage inventory in the face of competing orders
  3. home-prj order book replication in 2 coding interviews — Jump + iRage
  4. home-prj FIX client/server https://github.com/tiger40490/repo1/tree/jProj/java/com/tanbinFIX
  5. home-prj swing GUI to auto-update a table viewer

 

Advertisements

2 pitfalls on my accu path #portable,MktDepth..

Say you stay in one team for 5 years, hoping to accumulate expertise and insight

  1. Trap: local system knowledge, not portable
    • eg: Qz
    • Tibrv wrappers in 95G is not so bad
  2. Trap: poor market depth
    • eg: vol fitter
  3. Trap: limited standardization across companies.
    • eg: cryptocurrency
    • eg: OMS?
    • eg: mkt data dissemination cf raw mkt data parsing

##orgro lens:which past accu proved long-term # !! quant

(There’s a recoll on this accumulation lens concept…. )

This post is Not focused on IV or GTD. More like zbs.

Holy grail is orgro, thin->thick->thin…, but most of my endeavors fell short. I have no choice but keep shifting focus. A focus on apache+mysql+php+javascript would have left me with rather few options.

  • —-hall of famers
  • 1) [T] data structure theory + implementation in java, STL, c# for IV — unneeded in projects
  • 2) [CRT] core java knowledge including java OO has seen rather low churn,
    • comparable to c++
    • much better than j2EE and c#
  • 3) [T] threading? Yes insight and essential techniques. Only for interviews. C# is adding to the churn.
  • 4) [j] java/c++/c# instrumentation using various tools. Essential for real projects and indirectly helps interviews
  • [C] core C++ knowledge
  • [C] GTD knowledge in perl/python/sh scripting
  • [j] google-style algo quiz — Only for high-end tech interviews. Unneeded in any project
  • [R] SQL? yes but not a tier one skill like c++ or c#
  • coding IV — improved a lot at RTS
  • ————————also-ran :
  • devops
  • [C] personal productivity scripts
  • [T] probability IV
  • [C] regex – needed for many coding interviews and real projects
  • [C] low level C skills@RTS {static; array; cStr; reinterpret_cast;  enum; typedef; namespace; memcpy}
  • [!T] bond math? Not really my chosen direction, so no serious investment
  • [!T] option math?
  • SQL tuning? not much demand in the trading interviews, but better in other interviews
  • [R] Unix — power-user GTD skills.. instrumentation, automation? frequently used but only occasionally quizzed
  • [R] Excel + VBA? Not my chosen direction

–strengths
C= churn rate is comfortable
D = has depth, can accumulate
R= robust demand
T= thin->thick->thin achieved
j|J = relevant|important to job hunting

[18]top 4 IV(!! GTD)domains 2 provide 20Y job security

See also

Let’s ignore zbs or GTD or biz domains like mktData/risk here …

  • –roughly ranked by value-to-me
  • [c s] java? resilient in the face of c# and dynamic languages. At least 10Y relevance.
  • [c s] c++? resilient in the face of java. Time-honored like SQL
  • [c] abstract algorithm and data structures, comp science problem solving
  • [c n] tcp/udp optimization + other hardware/kernel/compiler optimizations
  • ……….No more [c]
  • py + shell scripting? no [c] rating since depth unappreciated
  • Linux and windows? at least 10Y growth, but no [c]
  • [s] SQL? resilient in the face of noSQL, but no [c]
  • bond math?
  • [n s] FIX? At least 10Y relevance
  • [c=high complexity in IV; shelf-life; depth appreciated …]
  • [n=niche, but resilient]
  • [s=survived serious challenges]

%% poor accu ] quantDev: Sg+U.S.

My past experiences are underwhelming. I thought that once I become experienced and proven in quant dev domain, things will be easier and I could move from one job to another. Wrong!

  • Barclays? helped me get into OC since OC interviewers are interested in how things are done in Barclays. Didn’t really help me go anywhere else
  • Stirt? helped me a bit with Mac interview
  • MSFM? didn’t help me get anywhere, partly because I didn’t try.

OC/Stirt/Mac gave me no insight no breakthrough in my understanding no thick->thin->thick

The number of quant dev positions is much fewer than in market data!

c#/c++/quant – accumulated focus

Update — such a discussion is a bit academic. I don’t always have a choice to focus on one area. I can’t afford to focus too much. Many domains are very niche and there are very few jobs.

If you choose the specialist route instead of the manager route, then you may find many of the successful role models need focus and accumulation. An individual’s laser energy is a scare resource. Most people can’t focus on multiple things, but look at Hu Kun!

eg: I think many but not all the traders I know focus for a few years on an asset class to develop insight, knowledge, … Some do switch to other asset classes though.
eg: I feel Sun L got to focus on trading strategies….
eg: my dad

All the examples I can think of fall into a few professions – medical, scientific, research, academic, quant, trading, risk management, technology.

By contrast, in the “non-specialist” domains focus and accumulation may not be important. Many role models in the non-specialist domains do not need focus. Because focus+accumulation requires discipline, most people would not accumulate. “Rolling stone gathers no moss” is not a problem in the non-specialist domains.

I have chosen the specialist route, but it takes discipline, energy, foresight … to achieve the focus. I’m not a natural. That’s why I chose to take on full time “engagements” in c#, c++ and UChicago program. Without these, I would probably self-teach these same subjects on the side line while holding a full time java job, and juggling the balls of parenting, exercise, family outings, property investment, retirement planning, home maintenance….[1] It would be tough to sustain the focus. I would end up with some half-baked understanding. I might lose it due to lack of use.

In my later career, I might choose a research/teaching domain. I think I’m reasonably good at accumulation.

–See also
[1]  home maintenance will take up a lot more time in the US context. See Also
https://1330152open.wordpress.com/2015/08/22/stickyspare-time-allocation-history/ — spare time allocation
https://1330152open.wordpress.com/2016/04/15/set-measurable-target-with-definite-time-frame-or-waste-your-spare-time/
https://1330152open.wordpress.com/2016/04/26/spare-time-usage-luke-su-open/

job4accu@20Y: which past job was closest2ideal

Q: do I want to deepen and specialize in one single area, rather than diversify? skill: deepen^diversify^stack up provides a context
A: let’s assume answer is yes deepen.

Q: which area?
A: programmatic data analysis in finance … with two entry barriers in math and coding, with reasonable “moneyness” but market depth is poor.
A: financial enterprise app with multi-threading …?
A: high speed market data engine in TCP/multicast?
A: orderbook replication with retransmission?
A: bond math including IRS?
A: option math? Poor market depth

Once we figure out which domain is good enough (very few), then we need a good boss…

So which past job is most likely to offer me that professional growth prospect?

  • 95G — java threading for trade execution
  • Barcap, but market depth is poor for that skill
  • citi?
  • RTS? but I get NO exposure to the raw sockets and I’m not allowed to ask!

前辈civil engineer^old C programmers

Opening example — I shared with Wael… If you meet a regular (not a specialist) civil engineer aged 50, you respect and value his skills, but what about a C programmer of the same age? I guess in US this is similar to a civil engineer, but in SG? Likely to be seen with contempt. Key is the /shelf-life/ of the skill.

Look at Civil engineers, chemical engineer, accountant, dentists, carpenters or history researchers (like my dad). A relatively high percentage of those with 20Y experience are 前辈. These fields let you specialize and accumulate.

In contrast, look at fashion, pop music, digital media… I’m not familiar with these professions, but I feel someone with 20Y experience may not be 前辈. Why? Because their earliest experiences lose relevance like radioactive decay. The more recent the experience, the more relevant to today’s consumers and markets.


Now let’s /cut to the chase/. For programmers, there are some high-churn and some “accumulative” technical domains. It’s each programmer’s job to monitor, navigate, avoid or seek. We need to be selective. If you are in the wrong domain, then after 20Y you are just an old programmer, not a 前辈. I’d love to deepen my understanding of my favorite longevity[1] technologies like

  • data structures, algos
  • threading
  • unix
  • C/C++? at the heart or beneath many of these items
  • RDBMS tuning and design; SQL big queries
  • MOM like tibrv
  • OO design and design patterns
  • socket
  • interactive debuggers like gdb

Unfortunately, unlike civil engineering, even the most long-living members above could fall out of favor, in which case your effort doesn’t accumulate “value”.

– C++ is now behind-the-scenes of java and c#.
– threading shows limited value in small systems.

[1] see the write-up on relevant55

–person-profession matching–
A “accumulative” professional like medical research can 1) be hard to get in and 2) require certain personal attributes like perseverance, attention to details, years of focus, 3) be uninspiring to an individual. Only a small percentage of the population get into that career. (Drop-out rate could be quite high.)

For many years in my late 20’s I was completely bored with technical work, esp. programming, in favor of pre-sales and start-up. But after my U.S. stay I completely changed my preferences.

(arch) xp I hope to accummulate

Architecture is all about design trade-off. Each time I start on a new technology, I want to grow as a hands-on architect. I hope to gain a bit of insight on the real drawbacks of the most common designs in that technology. I am not satisfied with the glossy brochures. They tend to play up many “shortcomings” that are irrelevant to my projects.

In the Quartz system, I don’t feel I learned what I wanted. I didn’t notice some common design I could *reuse* when I design my next system…

Guardian actually gave me such an opportunity, because it’s so simple, but I didn’t get to play with multiple working designs. The one component that actually worked well is the embedded web server I whipped up.

I foresee that with swing and WPF I would have more opportunities to “play with” various designs and get some insight.

I foresee that with javascript and php I would have that chance too.

Python?

[07] questioning accumulation as sys architect

You have repeatedly focused on accu.

@55, if u accumulate 5 years of lead-architect xp, it’s like to help tanbin’s sy1 (tanbin is suitable for it) even though
* even though In 2029 sg AR outside finance may earn less than many non-AR roles in US
* even though many of your peers might be in more glamorous roles in other countries earning more
* even though process differs from telco to telco — xp
* even though once-dominant technologies subside. Consider Raymond, Software AG, novell, Notes, Infomix…
* even though in many jobs and in many domains, accu is /elusive/
* even though — xp — you were frequently distracted by dotcoms, sunrise domains …
Q: how fast to become an large sys AR
If it takes years, then let’s accumulate now. Don’t diversify into PHP, DBA or SAP
Q: if not in US, then in SG?
perhaps lower pay than a non-AR role in US. Not greed.
Q: u feel AR adds more value than other roles, but it could be an internal system or a new, unproven service?
A: Still, AR tend to add more value.

labels: skillist^specialize^accu^domainBet^10yDirection

Skillist — the leaf-level tech skills. This label is most relevant on old posts without label.

pickDomain — helps me choose which industry sector to invest my time and accumulate.

specialize — I’m a specialist type of professional, not a generalist or manager. These posts help me position myself, not necessarily restricting to a particular domain.

accu — less specific than “specialize”

accumulated domain xp fetching salary premium@@

Update: Sanjay in Stirt felt his domain xp should be protective but no. GTD was key in that team.

DaShan: Prior Domain experience may not translate into higher code quality or productivity on the next job, due to restrictions and important differences between systems.

salary depends on many factors like

– budget and company size
– relationship with the site owner
– urgency
– domain experience

When I first met DaShan, I felt he has some invisible upper hand as a developer with that domain experience. I felt that way because of the ignorance or “lack of domain knowledge”. Now I know that other people also see me with that Halo.

How about the high math of MSFM?