focus+engagement2dive into a tech topic#Ashish

(Blogging. No need to reply)

Learning any of the non-trivial parts of c++ (or python) requires focus and engagement. I call it the “laser”. For example, I was trying to understand all the rules about placing definitions vs declarations in header files. There are not just “3 simple rules”. There are perhaps 20 rules and they have exceptions. To please the compiler and linker you have various strategies.

OK this is not the most typical example of what I want to illustrate. Suffice to say that, faced with this complexity (or ambiguity, and “chaos”) many developers at my age simply throw up their hands. People at my age are bombarded with kids’ schooling, kids’ enrichment, baby-sitting, home repair [1], personal investment [2], home improvement… It’s hard to find a block of 3 hours to dive in/zoom in on some c++ topic.

As a result, we stop digging after learning the basics. We learn only what’s needed for the project.

Sometimes, without the “laser”, you can’t break through the stone wall. You can’t really feel you have gained some insight on that topic. You can’t connect the dots. You can’t “read a book from thin to thick, then thick to thin again”. You can’t gain traction even though you are making a real effort. Based on my experience, on most of the those tough topics the focus and engagement is a must.

I’m at my best with my “laser”. Gaining that insight is what I’m good at. I relied on my “laser” to gain insights and compete on the job market for years.

Now I have the time and bandwidth, I need to capitalize on it.

[1] old wood houses give more problems than, say, condos with a management fee

[2] some spend hours every day

I know more c++than c#(spent X years full time)

Action: spend enough (30?) hours revisiting my 1000+ cpp (including socket, stream..) blog posts and explore just a little beyond them.

(I blogged about exactly the same observation before …) Here’s a paradox — i spent 2 years in a full time c# job, arguably longer than my full time c++ experience. However, sometimes I feel I understand dotnet less than C++.

Reason? Many aspects of the languages are never used in-depth on work projects, so length of experience != depth of experience. We need spare time self-exploration to learn those aspects like:

– template meta programming
– custom operator new/delete
– memory tuning
– memory leak detection
– threading
– async communications
– pure virtual
– ++i vs i++

(… not a complete list by any measure.) Interviewers are notorious for testing these obscure or advanced, theoretical topics.

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


zbs+nlg insight accumu due to X years@a job: !by default

Many interviewers assume the length of using something on a full time job indicates accumulation… Other interviewers test the depth of your insight.
You know you have insight, mileage, accumulation if/when ..
  • ..when  you know most of the important and relevant [1] terms in the lingo. Interviewers often go deeper about a new “construct”[2], and question its motivation/history and limitations.
    • ….if you know the __connections__ between the concepts. Without a mental map, there would be way too many unconnected lingo terms leading to info overload
    • ….if you know what new developments are only marginally important to your field, so you can focus on the really important
  •   ..if you can /separate the wheat from the chaff/滥竽充数/. I think often the real veterans would exchange a secret handshake and acknowledge each other very quickly. Eg: Dad (Tan Jiajian) knows his peers in the domain.
    • …. If you can’t quickly separate the wheat from the chaff, then probably you aren’t experienced enough.
  • ..when  you know you have grown much stronger than a junior person new to the field. How soon this happens is poorly correlated to # years
  • ..when your mental “book” has grown thin -> thick -> thin. Eg: math..
  • ..when you know you can master a “local” system quickly, thanks to the accumulation /under your belt/. Eg: Avichal Gupta…
As you can see, many of the indications/evidence of insight are related to evaluative discussions (including interviews). I’m not being narrow-minded and focus exclusively on job interviews. No. In any team,  very quickly person A would size up person B (and vice versa), and often have a rough number in his head about “how much B knows our shared domain”.
[1] it’s subjective but I feel 90% of what consider irrelevant is clearly irrelevant.
[2] this includes new choice, technique, best practice
German said one needs to be in a project for 6Y, but I disagree. I feel a wide range of non-trivial challenges is more important, and I feel we are unlikely to get that by staying in one project.
eg Perl — I used Perl for 3 to 5 years..
eg SQL — I used SQL for many years before GS, but my accumulation was solely in GS!
eg Threading — not much used. Mostly accumulation by reading…
eg option math –
eg C++ — see post on c++IV: knowledge more important than coding experience

IV^GTD – grow as techie@WS

I want to grow stronger/broader/versatile as a survivor, not necessarily grow my value-add. Actually I don’t have to grow.
— IV skills – Compared to GTD skills, these skills give me more confidence, more protection, more stress-relief. It works in big job markets like Wall St.

Lots of theory, which is my sweet spot.
Selective on what IV topics to learn!
coding IV + algo — favored by SiV
— (portable) GTD skills
Lots of tools….
Selective on what GTD topics to learn!

Needed for a lead developer, but such a role is stressful. I guess some good lead developers are also good at IV, but I’m not sure and I assume I’ll not be good at both.

Warning – a lot of projects don’t provide real GTD enrichment. Eg: Quartz, tibrv wrappers, Gemfire wrappers, FIX wrappers
Macquarie environment lets me learn lots of GTD skills.
OC gave me IV (c#) and GTD enrichment.
Stirt – none!

A java environment would give me some additional GTD enrichment but less IV enrichment

In SG, I continued my previous strategy, learning IV skills + GTD skills. Not effective so far. I feel my c# IV skills improved a lot but still not there. C++ IV skills didn’t improve much partly due to distractions.


## once-valuable skills – personal experience

perl – lost to python
tomcat, weblogic, jboss
apache, mysql
dns, unix network config
autosys – not used after GS
[$] sybase, oracle – after ML edge project I didn’t need it again.
[$] VBA – used once only. But Excel is going strong!

[$ = still has value]

–random list (not “top 10”) of longevity skills
eclipse, MSVS
Excel and add-in
STL, boost
javascript, though I don’t use it in my recent jobs
Linux shell
compiler skills
make, msbuild
bash and DOS batch scripting, even though powershell, vbscript and python/perl are much richer.