##what defined %%self-img ]each period

See posts on time allocation. Those things I overspent time on tend to be what defined me.

Income alone is never an item. Instead, “Earning capacity due to …..” is often one of the defining features.

In This list I prefer one-word items.

  • till high school, what defined me was nothing but
    • grades
    • simple focus and dedication, driven by academic ambition
  • NUS ( grades became mediocre even though I worked very hard towards Dean’s list )
    • academic ambition -> commercial ambition
  • 1999 – 2002
    • wizard — salary (due to my wizardry) was high but gradually became just about average
  • 2002 SCS – …
    • bizwing
  • 2007 – 2012
    • IV — in java, c++, swing, dnlg … became my killer skill
      • billing rate
    • tech zbs — (“GTD”? No) zbs was my focus even though i was not really outstanding
  • Aug 2012 – Apr 2017. Focus was finally lost. I became “interested in” many other things
    • wealth preservation, income maintenance — became the #1 undercurrent
      • MSFM was part of “income maintenance” effort
      • properties became the main part of wealth preservation and retirement planning
      • (alternative income source (rental, per investment, trading) — became a temporary focus and never get big)
    • I also defined myself as a dedicated and serious father to Yixin, not really hoping to produce a prodigy, but to shape his character and habits, and help him find his motivation.
  • now
    • IV and tech learning
    • continuous push to go deeper, further and increase zbs
    • low burn rate, conserver lifestyle

Hope to regain motivation and sharpen focus on c++, exchange conn and grow another “wing”

low budget,high effort projects – avoid^accept

Fanny (the Indian young entrepreneur in Agilent) and Zhang Jun pointed out that if you look for $500 projects you will find them and if you look for $100k projects you will find them too and not much harder.

A Wall St developer isn’t that much more hardworking or smarter than a main-street developer. The effort in a project is not much higher, once you get used to it, but the compensation is much higher.

Now the key thing — in a Wall st IT project team, some parts (like A1) have higher budget in terms of man-day than other parts (like B1) so the B1 guy must work hard to get things done more quickly. Yet unappreciated.

In another unfair situation, A2 and B2 have similar man-day budget but the values are vastly different. Yet the B2 part may have equally stringent requirements. Consider a logger — High performance, high reliability. So the B developer works hard but unappreciated.

eg: I think the commissions team is under-appreciated than trading or pricing teams. Similarly, regulatory, compliance, billing … Yes you can find good reasons to say these are critical and high value, but still their relative values  are lower.


I would say choose one among

gzCope, gzPain, gzThreat, GTD

In rare cases, use simultaneous categories.

Also, the relevant posts in the pripri/open blogs, I feel better move to this blog and mark them private. Easier to manage in one place.

GTD is more specific than Cope. In a sense, all GTD posts are also part of Cope but actually Cope is more about job market, moving up, choosing specializations.

## X years C++experience without using virtual !

  • It’s possible to code C for years without using pointers (except string functions), or malloc
  • It’s possible to code C++ for years without using virtual, new/delete, STL, or even class.
  • It’s possible to code java/c# for years without any threading, or reflection
  • It’s possible to code perl for years without using interesting regex or hard/soft references.
  • It’s possible to code SQL for years without writing outer joins. I guess I wrote lots of mysql queries without any join.
  • It’s possible to code python for years without creating python classes.
  • eg quartz — the python experience didn’t make a strong python developer. The other tech knowledge gained has even lower market value.

positioning yourself for the next TIDE#Avi, SunLin…

Background: Avichal pointed out ..”knowledge”. To excel in any domain we need mileage, valuable insight, non-trivial experience, and accumulation — non-trivial and doesn’t happen naturally. I have observed it with SQL, Java, Python, threading, trading system design …
Every job change presents an opportunity to reposition yourself. Bear in mind very few jobs put you right at the forefront. Positioning means incremental accu of relevant (often peripheral) knowledge. That’s probably the realistic way to assemble the jigsaw pieces.
You are unlikely to be given an architect role, but look at AOC!

## types of Work to slow/speed brain aging

This is an important topic for the researchers. As laymen, I will just reflect on my personal experience — looki.

What kind of activity is considered “work”? I feel it’s the responsibility or commitment, obligation, consequences …

Most but not all the “work” is tiring. I feel creative work can help keep the brain young.

IT — Learning a new tech in body-building mode doesn’t feel tiring to me, but how about to XR?
IT — A big chunk of everyday IT work (including troubleshooting) is partly creative and investigative. Can be brain-boosting.
Kids doing homework – can be tiring but at their age it won’t speed brain aging. How about adults?

local jargon, local domain knowledge #le2friend

I agree that finance IT skills tend to “converge” across big banks, so we poor developers need not learn so many damn shit new stuff like GIT.

On the domain knowledge side, the “local system knowledge” has no convergence as such, so each time I take up a new system, I must spend the time on the stored procs, table relationships, batch jobs, feed files, etc. There are also a lot of non-technical local knowledge. I hear you when your manager complained “what do you know about the system?”

Local system knowledge can be a long learning curve. Those who write the code in the first place has a huge advantage —

“It takes me 3 months to write this damn shit, then we add new features and fix bugs, but it’s still familiar to me. A new guy would take a year to get familiar code-wise, provided he has chance to explore all the key components. If he’s only exposed to half the system, then he would never know  the other half.”

(Therefore, I like to rewrite stuff.)

In http://bigblog.tanbin.com/2011/04/3-types-of-domain-knowledge-in-finance.html I mentioned 3 types of domain knowledge – Jargon, Math, and Architecture.The Math part is stable. Local system knowledge includes a lot of local jargon. Sometimes generic jargon can help us pick up the local jargon.