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

Advertisements

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

master a skill^depend@colleagues – you decide!

Nikhil surprised me when he told me he frequently asks for help… Until then, I always thought I need to go through the problem solving by myself, unaided, or I will never learn.


Context — trading engine team workload is often 3 times the normal, comfortable level. Headcount is often below 33% normal headcount. (This is a result of time-to-market delivery experience — The fewer developers, the lower communication overhead, the more nimble.)

Challenge – Suppose you are suddenly asked to finish something quick and dirty in half the time previously allocated.

Higher pressure usually means you need to depend more heavily on other developers in your own team. Many things you should not *want* to understand. You need to decide what analysis/research/investigation to “outsource”, but still retain control.

A component could be your colleague’ responsibility, but familiarity improves your *velocity* and reduces your reliance on the author. With mastery, you often discover tweaks and shortcuts, saving time when there’s no time at all. You can become more knowledgeable than the author about its usage!

Look at GS colleagues Nikhil, Anil, Nicholas… They ask each other dozens of questions for everyday BAU, but each mastered how to read and experiment with JIL, sybase stored proc, CVS, unix commands, …They don’t master every subject, and they don’t lean on others in every domain.

Eg: how to programatically insert reference data into an empty data store, rather than through a complicated (buggy) GUI. The GUI route is un-automated if you must repeatedly rebuild from scratch.
Eg: key tables. Out of 20 to 50 frequently used tables, about 2 to 5 tables should be familiar to everyone, like Comm, trade, offer. Before you go through these steep learning curves, you aren’t initiated into the club.
Eg: how to locate and parse the logs
Eg: how to test-send and test-receive messages
Eg: how to restart some of the important servers
Eg: how to identify common issues in each essential server
Eg: parse a few cornerstone config files
Eg: parse autosys JIL to see dependencies and flows

But as a Greenfield dev consultant, you aren’t expected to get too deep into prod support or BAU.

A short-term greenfield developer consultant is not a “Subject Matter Expert”.

## X years C++xp 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

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!