前辈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.

##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.

labels: cope^pain^threat^GTD

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.

## 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.

hobbies generating positive-stress – le2 Amina

I feel if a person has multiple personal goals and they generate positive stress (rather than pressure), then these goals enhance this person's condition stress-wise. Each such stressor is a power pump with a safety valve.

For eg, i try to publish some worthwhile blog post every week. Never stressed me out.
For eg, in my early 30's I used to attend a quarterly fitness test
For eg, I was improving my coding (c++/c# etc) in my spare time — i do feel a bit disappointed if i make no progress for a month, but this pressure is still small, compared to many external stressors in my life:)
For eg, I used come to office on weekends and work on unfinished tasks. Not forced to.
For eg, I used to try job interviews when my job is safe. Would be real stressful if job is under threat.
For eg, helping my son with piano and swimming practice can feel stressful, but there's a ….. safety valve.

FW: grab a critical component (and make it unnatural for other developers:)

XR,

I now see more wisdom in such a “job protector”.

I feel a critical component could be

– the release process like the one your colleague controls

– build process

– some scheduling tool like autosys. You can make it very complicated.

– some home-made diagnostic tool to troubleshoot a critical component.

– some wrapper component that everyone must go through to access messaging, or some critical library…

– some very important SQL query? Well, colleagues can copy it and figure out how it works. It's “more effective” if there are many such queries and these queries need a lot of tweaking each time. Then no one can become familiar with these queries and replace me!

a few ideas on how to manage the manager #OCBC

This is about a generic manager, not a particular person☺. I will use “she” or “he” interchangeably.

• Result or reason? Managers want results, not reasons. When she asks me for a reason, what she really wants is how she can help solve the problem and make progress towards the result.

• I don't disclose my actual implementation details. If managers ask, I try to avoid the details. I feel managers don't want to be bothered with implementation details, esp. when the codebase grows big and my module is outside the most critical 10% core modules.

• I seldom deviate from manager's technical direction. If I must deviate, I try to keep a low profile and get things to work quickly. If I miss a deadline and attracts his question, then I try to give a reason without disclosing my deviation.

• When things get unbearable, I tell myself I am not imprisoned for life here.

• When I receive a put-down remark, I remind myself I'm competent and I generally get things done, and I am respected by my colleagues.

• When asked about progress, I used to give a guarded response like “working but there are some questions about ….”.