Y alpha geeks keep working hard #speculation

Based on my speculation, hypothesis, imagination and a tiny bit of observation.

Majority of the effective, efficient, productive tech professionals don’t work long hours because they already earn enough. Some of them can retire if they want to.

Some percentage of them quit a big company or a high position, sometimes to join a startup. One of the reasons — already earned enough. See my notes on envy^ffree

Most of them value work-life balance. Half of them put this value not on lips but on legs.

Many of them still choose to work hard because they love what they do, or want to achieve more, not because no-choice. See my notes on envy^ffree

by-level traversal: isBST #Ashish

Q: given a sequence of payload values produced from a by-level traversal of a binary tree, could the tree be a BST?

Ashish gave me this question. We can assume the values are floats.

====analysis

(Not contrived, not practical)

— idea 1:

Say we have lined up the values found on level 11. We will split the line-up into sections, each split point being a Level-10 value.

Between any two adjacent values on level 10 (previous level), how many current-level values can legally fit in? I would say up to 2.

In other words, each section can have two nodes or fewer. I think this is a necessary (sufficient?) condition.

–idea 2: One-pass algo

Construct a BST as we consume the sequence.

Aha — there’s only one possible BST we can build.

 

(unordered)map erase: prefer by-key !! itr #Ashish

Relevant in coding tests like speed-coding, take-home, onsite. Practical knowledge is power !

As shown in https://github.com/tiger40490/repo1/blob/cpp1/cpp/lang_misc/mapEraseByVal.cpp

.. by-key is cleaner, not complicated by the iterator invalidation complexities.

You can save all the “bad” keys, and later erase one by one, without the invalidation concerns. You can also print the keys.

if you were to save the “bad” iterators, then once you erase one iterator, are the other iterators affected? No, but I don’t want to remember.

STL iterator invalidation rules, succinctly has a succinct summary, but I don’t prefer to deal with these complexities when I have a cleaner alternative solution.

std::pair mvctor = field-by-field

std::pair has no pointer field so I thought it needs no meaningful mvctor, but actually std::pair mvctor is defaulted i.e. field-wise move i.e. each field is moved.

If a pair holds a vector and a string, then the vector would be move-constructed, and so does the string.

Q1: So what kind of simple class would have no meaningful mvctor?
%%A: I would say a class holding no pointer whatsoever. Note it can embed another class instance as a field.

Q2: so why is std::pair not one of them?
A: std::pair is a template, so the /concrete/ field type can be a dynamic container including std::string.

All dynamic containers use pointers internally.

## identify your superior-absorbency domains

  1. When in sky-high absorbency, you should try and take on the _really_tough_.
  2. When in “good” absorbency, you should take on the medium tough jobs.

Before goggles, swimmers compete by increasing the amount of practice, which was limited by the capacity of their eyes to endure the “abuse” — I call it “capacity”, and sometimes “absorbency”, as defined in two blogposts ##absorbency[def#2]worn_out by endeavors #coding and My absorbency[def#1

Myself as an illustration — Compared to my peers, I have superior Long-term absorbency/capacity for these *specific* challenges:

  • best eg: jogging, but not stretching. I have much higher capacity to cope with jogging then stretching. I don’t really need to capture the motivation for jogging.
  • I have higher capacity for push-up practice compared to chin-up practice.
  • eating raw veg but not celery or raw carrot
  • delaying meals but not reducing dinner

These long-term absorbency advantages are truly life-enhancing, to put it mildly…

— bigger eg: theoretical QQ study more than coding drill — major competition.

For many peers, when they find the fleeting motivation to study QQ, they should capture it. I don’t have to.

Ken Li said something like … If you enjoy tech and esp. dev work, then you have job security in tech sector till old age. I think he said that because there are so many tech jobs in U.S. not so demanding, where my absorbency advantage alone is more than sufficient to sustain a long career.

— bigger eg: java QQ more than c++ QQ

I have much easier learning journey on java. More satisfying, more Aha. I feel more in control, and less “lost”. I see more logical connections. The fundamental designs make more sense to me.

j4 selective listening

Selective listening is not so wrong.

We Need selective listening.

Some information, tips, suggestions, facts-n-figures do more harm than good to us. Our mind is not so strong so rational, therefore it can be polluted, influenced… Easily

eg : the Internet millionaire on youtube. I used to say “even though I hate his face he might be a good guy just too polished.” I used to dismiss my more cynical Chinese friends as prejudiced, opinionated …. until Hongzhi told me some Eric was a 骗子. Then I met another in my very first public speech given at Woodlands library, to 20 interested investors.

I now tune in to my first impressions, my instincts and my gut feelings, even though they are not fair, balanced at all. If I always suspend these unfounded assessments, I would listen to hoaxes all the time.

fine print]source code

Q1: “Here is 90% of the logic” — when is such a documentation complete? Answered at the end.

When we programmers read source code and document the “business logic” implemented thereby, we are sometimes tempted to write “My write-up captures the bulk of the business logic. I have omitted minor details, but they are edge cases. At this stage we don’t need to worry about them”. I then hope I have not glossed over important details. I hope the omitted details are just fine prints. I was proven wrong time and again.

Sound byte: source code is all details, nothing but details.

Sound byte: Everything in source code is important detail until proven otherwise. The “proof” takes endless effort, so in reality, Everything in source code is important detail.

The “business logic” we are trying to capture actually consists of not only features and functionalities, but functional fragments i.e. the details.

When we examine source code, a visible chunk of code with explicit function names, variable names, or explicit comments are hard to miss. Those are the “easy parts”, but what about those tiny functional fragments … Perhaps a short condition buried in a complicated if/while conditional? Perhaps a seemingly useless catch block among many catches. Perhaps a break/continue statement that seems serve no purpose? Perhaps some corner case error handling module that look completely redundant and forgettable, esp. compared to other error handlers. Perhaps a missing curly brace after a for-loop header?

( How about the equal sign in “>=” … Well, that’s actually a highly visible fragment, because we programmers have trained vision to spot that “=” buried therein. )

Let me stress again. The visibility, code size … of a functional fragment is not indication of its relative importance. The low-visibility, physically small functional fragments can be equally important as a more visible functional fragment.

To the computer, all of these functional fragments are equally significant. Each could have impact on a production request or real user.

Out of 900 such “functional fragments”, which ones deal with purely theoretical scenarios that would never arise (eg extraneous data) .. we really don’t know without analyzing tons of production data. One minor functional fragment might get activated by a real production data item. So the code gets executed unexpectedly, usually with immediate effect, but sometimes invisibly, because its effect is concealed by subsequent code.

I would say there are no fine-prints in executable source code. Conversely, every part of executable source code is fine print, including the most visible if/else. Every executable code has a real impact, unless we use real production data to prove otherwise.

A1: good enough if you have analyzed enough production data to know that every omitted functional fragment is truly unimportant.

intellij=cleaner than eclipse !

intellij (the community version) is much cleaner than eclipse, and no less rich in features.

On a new job, My choice of java ide is based on
1) other developers in the team, as I need their support

2) online community support — as most questions are usually answered there
I think eclipse beats intellij

3) longevity — I hate to learn a java ide and lose the investment when it loses relevance.
I think eclipse beats intellij, due to open-source

)other factors include “clean”

The most popular tools are often vastly inferior for me. Other examples:
* my g++ install in strawberryPerl is better than all the windows g++ installs esp. msvs
* my git-bash + strawberryPerl is a better IDE than all the fancy GUI tools
* wordpress beats blogger.com hands down
* wordpad is a far simpler rich text editor than msword or browsers or mark-down editors

java value-based types #Optional.java

Optional.java is the only important example I know, so I will use it as illustration.

One of the main ideas about value types is that they have no notion of identity (or perhaps their identity is detectable only to JVM not Java applications). In such a world, how could we tell whether variables aa and bb “really” are the same or different?

Q: why avoid locking on value-based objects?
%%A: locking is based on identity. See why avoid locking on boxed Integers
A: https://stackoverflow.com/questions/34049186/why-not-lock-on-a-value-based-class

c++ has a smaller community and collective brain power so discussions are more limited.

Y avoid us`boxed Integer as mutex

https://stackoverflow.com/questions/34049186/why-not-lock-on-a-value-based-class section on “UPDATE – 2019/05/18” has a great illustration

Auto-boxing of “33” usually produces distinct objects each time, but could also produce the same object repeatedly. Compiler has the freedom to optimize, just as in c++.

Remember: locking is based on object identity.

wage+cost levels: biased views@China colleagues

— salary

Many China colleagues (say YH as an example) say their classmates earn much more than them in the U.S.  These colleagues seem to be claim their Typical Chinese counterpart earns higher than in the U.S.

Reality — those classmates are outliers. The average salary in China is much lower than U.S. Just look at statistics.

I feel YH feels inferior and regret coming to the U.S.

— cost of reasonable lifestyle

Many Chinese friends complain that cost level is higher in China than U.S. and Singapore. A young MLP colleague (Henry) said a RMB 500k/year feels insufficient to a Chinese 20-something.

In reality, per-sqft property price is indeed higher in some cities than in the U.S. For almost everything else, China cost level is much lower than in the U.S. Just look at statistics.

success in long-term learning: keen!=interest

For both my son and my own tech learning over the long term, “interest” is not the best word to capture the key factor.

I was not really interested in math (primary-secondary) or physics (secondary). In college, I tried to feel interested in electronics, analog IC design etc but unsuccessful. At that level, extrinsic motivation was the only “interest” and the real motivation in me.

Therefore, the strongest period of my life to look at is not college but before college. Going through my pre-U schools, my killer strength was not so much “interest” but more like keenness — sharp, quick and deep, absorbency…

Fast forward to 2019, I continue to reap rewards due to the keenness — in terms of QQ and zbs tech learning. Today I have stronger absorbency than my peers, even though my memory, quick-n-deep, sharpness .. are no longer outstanding.

Optional.java notes

Q: if an optional is empty, will it remain forever empty?

— An Optional.java variable could but should never be null, as this instance need a state to hold at least the boolean isPresent.

If a method is declared to return Optional<C>, then the author need to ensure she doesn’t return a null Optional ! This is not guaranteed by the language.

https://dzone.com/articles/considerations-when-returning-java-8s-optional-from-a-method illustrates a simple rule — use a local var retVal throughout then, at the very last moment, return Optional.ofNullable(retVal). This way, retVal can be null but the returned reference is never null.

If needed, an Optional variable should be initialized to Optional.empty() rather than null.

–immutability is tricky

  1. the referent object is mutable
  2. the Optional reference can be reseated, i.e. not q[ final ]
  3. the Optional instance itself is immutable.
  4. Therefore, I think an Optional == a mutable ptr to a const wrapper object enclosing a regular ptr to a mutable java object.

Similarity to String.java — [B/C]

Compare to shared_ptr instance — [A] is true.

  • C) In contrast, a shared_ptr instance has mutable State, in terms of refcount etc
  • B) I say Not-applicable as I seldom use a pointer to a shared_ptr

— get() can throw exception if not present

— not serializable

— My motivation for learning Optional is 1) QQ 2) simplify my design in a common yet simple scenario

https://www.mkyong.com/java8/java-8-optional-in-depth/ is a demo, featuring … flatMap() !!

OO-modeling: c++too many choices

  • container of polymorphic Animals (having vtbl);
  • Nested containers; singletons;
  • class inheriting from multiple supertypes ..

In these and other OO-modeling decisions, there are many variations of “common practices” in c++ but in java/c# the best practice usually boils down to one or two choices.

No-choice is a Very Good Thing, as proven in practice. Fewer mistakes…

These dynamic languages rely on a single big hammer and make everything look like a nail….

This is another example of “too many variations” in c++.

dev jobs ] Citi SG+NY #Yifei

My friend Yifei spent 6+ years in ICG (i.e. the investment banking arm) of Citi Singapore.

  • Over 6Y no layoff. Stability is Yifei’s #1 remark
  • Some old timers stay for 10+ years and have no portable skill. This is common in many ibanks.
  • Commute? Mostly in Changi Biz Park, not in Asia Square
  • Low bonus, mostly below 1M
  • VP within 6 years is unheard-of for a fresh grad

I feel Citi is rather profitable and not extremely inefficient, just less efficient than other ibanks.

Overall, I have a warm feeling towards Citi and I wish it would survive and thrive. It offers good work-life balance, much better than GS, ML, LB etc

debugger stepping into library

I often need my debugger to step into library source code.

Easy in java:

c++ is harder. I need to find more details.

  • in EclipseCDT, STL source code is available to IDE ( probably because class templates are usually in the form of header files), and debugger is able to step through it, but not so well.

Overall, I feel debugger support is significantly better in VM-based languages than c++, even though debugger was invented before these new languages.

I guess the VM or the “interpreter” can serve as an “interceptor” between debugger and target application. The interceptor can receive debugger commands and suspend execution of the target application.

complacent guys]RTS #DeepakCM

Deepak told me that Rahul, Padma etc stayed in RTS for many years and became “complacent” and uninterested in tech topics outside their work. I think Deepak has sharp observations.

I notice many Indian colleagues (compared to East European, Chinese..) uninterested in zbs or QQ topics. I think many of them learn the minimum to pass tech interviews. CSY has this attitude on coding IV but the zbs attitude on socket knowledge

–> That’s a fundamental reason for my QQ strength on the WallSt body-building arena.

If you regularly benchmark yourself externally, often against younger guys, you are probably more aware of your standing, your aging, the pace of tech churn, … You live your days under more stress, both negative and positive stress.

I think these RTS guys may benchmark internally once a while, if ever. If the internal peers are not very strong, then you would get a false sense of strength.

The RTS team may not have any zbs benchmark, since GTD is (99.9%) the focus for the year-end appraisal.

These are some of the reasons Deepak felt 4Y is the max .. Deepak felt H1 guys are always on our toes and therefore more fit for survival.