GTD/KPI/zbs/effi^productivity defined#loosely

  • GTD – make the damn thing work. LG of quality, code smell, maintainability etc
  • KPI – boss’s assessment often uses productivity as the most important underlying KPI, though they won’t say it.
  • productivity – GTD level as measured by __manager__, at a higher level than “effi”
  • effi – a lower level measurement than “Productivity”
  • zbs – real, core strength (内功) of the tech foundation for GTD

skill: deepen^diversify^stack up

Since 2010, I have carefully evaluated and executed 3 broad strategies:

  1. deepen – for zbs + IV
  2. diversify or branch-out. Breaking into new markets
  3. stack-up – cautiously
  • eg: Deepened my java/SQL/c++/py knowledge for IV and GTD. See post on QQ vs ZZ.
  • eg: diversified to c++, c#, quant, swing…
  • eg: diversify? west coast.
  • eg: diversify? data science
  • eg: diversify? research + teach
  • eg: stack-up to learn spring, hibernate, noSQL, GWT.

Stack-up — These skills are unlikely to unlock new markets. Lower leverage.

GTD stress/survival on the job? None of these help directly, but based on my observation GTD skill seldom advance my career as a contractor. It could create a bit of spare time, but it’s a challenge to make use of the spare time.

I feel German’s strategy goes beyond tech skills. He treats tech skills as a tool, used to implement his business ideas to create business value. I feel his target role is a mix of architect/BA but more like “product visionary”. It’s somewhat like stack-up.

c++GTD^IV muscle building: X years xp: U can cut by half

What specific topics to improve for c++ (not pure algo) coding IV? (X years experience doesn’t guarantee anything)

  • · Write code to print alternative item reversely
  • · Write ref-counted string
  • · Write auto-ptr

What specific topics to improve for c++ QnA IV? (X years experience doesn’t guarantee anything)

So in any of these areas, x years spent using a language could leave you still total beginner!

##accumu lens:which past accumulations(zbs+)proved long-term

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

Holy grail is orgro, thin->thick->thin…, but most of my attempts failed.

I have no choice but keep shifting focus. A focus on apache+mysql+php+javascript would have left me with few options.

–hall of fame

  • 1) data structure theory + implementation in java, STL, c#
  • 2) [C  RT] core java 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] instrumentation in java codebase and to a lesser extent c#. Essential for real projects and indirectly helps interviews
  • [C] core C++
  • [j] google-style algo quiz? Only for high-end tech interviews
  • —-also-ran :
  • [!T] bond math? Not really my chosen direction, so no serious investment 
  • [!T] option math?
  • [R] SQL? yes but not a tier one skill like c++ or c#
  • SQL tuning? not much demand in the c++ interviews, but better in other interviews
  • regex – needed for many coding interviews and real projects
  • py? increasing use in projects
  • [R] Unix instrumentation, automation? frequently used but only occasionally quizzed
  • [R] Excel + VBA? Not my chosen direction

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

X years needed2become effective java GTD guy

Update — It would be good to have some measurable yardsticks for GTD competence. Right now the g_GTD_zbs tag includes at least 50 blogs.

XR, (letter sent in July 2010)

Here the goal is not getting the job but keeping the job. You said there’s a difference between a knowledgeable java student and an experienced java developer.

I said I only did java for 3 years.. well maybe 4. I think much of that time I was doing repetitive work, not learning. About half the time (1-2 years) I was learning, by experimenting, reading, discussing, debugging… (I actually learned a lot of java from our long phone conversations.)

I feel if a bright young guy is given a good training project, then in 6 – 24 months he might be able to reach my level of java proficiency.

I also said a lot of young coders could become faster than me with a specific java task after a few months of java learning. Well … an apprentice carpenter could become faster than his master at sawing along a line, but can’t replace the master completely. I feel the hundreds of decisions made each week by an experienced java developer are often based on more experience.

C# is probably same thing – 6 to 24 months to become effective. A very experienced c# friend told me “3 months”. I spent about 6 serious months and another 12 repetitive months on c#…

Venkat, one of the fastest-learning developers I have worked with, said (in Lau Pa Sa) “To get really competent with a new language (like java, c#, python) honestly you need at least one year.” Venkat had the strongest C++ skill I know. I witnessed how he picked up c#. He later struggled a bit with java.

The 64 million dollar question is, what are the really effective learning strategies. I don’t have good answers. Guo Qiao was an advocate of programmer online learning. Some people even suggest taking part in open source projects, to learn from practicing master programmers… I’d love to hear your input.


in-depth^cursory study@advanced programm`topics

I have seen both, and tried both.

AA) A minority of developers spend the time studying and understanding the important details of threading, generics, templates … before writing code.

BB) Majority of developers don’t have the time, vision or patience, and only learn the minimum to get the (sloppy) job done. They copy-paste sample code and rely on testing, but the test cases are limited to realistic UAT test cases and will not cover edge cases that have yet to occur. For concurrency designs, such tests are not good enough.

AA is often seen as unnecessary except:
* Interviewers often go in-depth
* In a product vendor rather than an in-house application team
* If requirement is unusual (eg: B2BTradingEngine), then BB won’t even pass basic developer self-tests. Sample code may not be available — see my post So developers must bite the bullet and take AA approach. This is my sweet spot. See

On Wall St projects, I learned to abandon AA and adopt BB.

On Wall St interviews, I still adopt AA.

On West Coast, I think AA is more needed.

##2017most used(GTD+)Generic know-how4Wall St developers

#1 java — the ecosystem
#2 c/c++ — not yet my chosen direction
#3 dotnet including c#, WCF, remoting, windows debugging …
#4 py — purely automation in most places(easy instrumentation); advanced py systems in a few places

# unix power user tools – including scripting, instrumentation… More widespread but depth is seldom required compared to SQL and python. More well-defined as a tech skill than windows dev.

# SQL/stored proc — losing pole position in low latency and big data environments, still dominant in traditional apps

# Excel add-in and automation

# javascript

establish tech stronghold(GTD+nlg)]each team

Note – focus is job performance, not IV.

To survive in a team,need unique technical specialty in a key area.

With the possible exception of the Citi Muni team, I have not seen a banking IT team to tolerate a “dead weight” guy. To do reasonably well in any financial IT team, I often need some “hard” strength (like an subject matter expertise), not just soft skill. If within your team you have a unique technical strength in a complex and important sub-system, then you can “name your price”, and you are kind of irreplaceable. Perhaps a go-to person. Some team members don’t have any expertise but survive on strong relationships. I’m unable to do that. In the past teams, I think many team members have such a strength. If I don’t have it, my position would be less established, less solid.

  • 😦 😦 stirt? Worst experience. Was good at the insignificant preferences framework; canceled trades
  • 😦 GS? Uncomfortable position. My Perl was not top notch. My java was below Yang. I became good at Error Memos (EOS) and trailers/upfronts
  • 🙂 OC? was good at Bloomberg adapter and Guardian builtin web server to show the log files
  • 🙂 🙂 95 Green? My DB design was convincing to Ravi. My wait-notify based design was pretty hard to match.
  • 🙂 Barc? FMD, fmath
  • 😦 Macquarie? In the quant team, whatever I accomplish seems trivial to manager, since he’s too strong. I’m seen as very slow on small tasks.