localSys,big codebase..taxing@the aging memory

A.Brooks talked about innovative brain power. I’m talking about memory capacity.

Now I see that localSys on a big system is taxing on the aging memory. I guess GregM (RTS) might be a cautionary tale. GregM relied on his theoretical knowledge to pass interviews, but not fast enough with local codebase

Is green field better than brown-field codebase? I guess so, based on personal experience. Green-field projects are rarely given to a new joiner but contractors are often hired on green field budget — like Citi, 95G, volFitter and RTS 🙂

Now consider this separate question:

Q: Are the c++11 QQ topics a form of churn on the interview arena?
A: Yes but c++11 QQ is lighter (on the aging memory) than localSys

Q: how about the Coding IV?
A: still lighter stress than localSys.

technology xyz is dead

I often hear people say “technology XX is dead” .. exaggerated attention-grabbing gimmick, common on social media user posts.

I like the “dead”, old-fashioned, time-honored, stable technologies that are robust (not only resilient) against churn.

The alternative technologies are use-less, worth-less, hope-less, less proven, low-value, more likely to die young or even dead-on-arrival

personal choices]team contexts #LS

Hope your family is coping well with covid19. The hand-washing habit reminds me of a past conversation, i.e. our last meal together, in a restaurant near your beautiful North Carolina home. Nice meal, not Chinese but some special cuisine (Greek?). A few months later, over a phone call you revealed several observations of my “unusual habits”. One was my habit of leaving my seat and washing my hands before the meal. You instructed me to imagine a team lunch where everyone including the boss has sat down. I said I would still follow my habit. In recent years, I have followed this same habit in many team lunches at many companies.

I remember asking you what to do given that I have a history of food poisoning due to missed hand-wash. I think you described it as a personal choice — choosing to prioritize hand hygiene, I may inadvertently create negative impressions among coworkers, opinions that might affect my future in the company. I once said I didn’t care much about such an impression or opinion. Even if I stop my personal habit, over several months of interaction, such opinions would emerge.

We all form opinions about coworkers. Some opinions are more directly related to work — quality, efficiency, integrity, dedication…. Other opinions are so subtle that sometimes I am ignorant or unconcerned about them.

By choice or by chance, I have not moved up in any team, but am satisfied with my situation and job prospect (contractor?). Therefore, even though I’m ignorant or unconcerned about many people’s opinions of me, I don’t feel I’m paying a price. (In contrast, I have paid big prices for some real mistakes in my career.)

Some habits create long-term or deeper damage, but this kind of hand-washing habit is not that damaging. In saying this, I try to avoid downplaying the reputation damage. I try to put things into perspective. Here I’m mostly talking about personal habits with relatively low impact on other people. I now feel your style of reasoning is very focused on other people’s impression. I feel it’s too unnatural, too hard for me, so I don’t want to live a life under this type of “suffering”.

Let me know your thoughts. I think you have come across people like me, possibly younger ones or older ones.

enough bandwidth2help kids study@@ : 3 past jobs

Which past jobs would allow me to spend more time helping kids with studies?

  1. #1 Citi — i can finish off personal work in office
  2. OC
  3. RTS? yes during the quiet weeks. More importantly, I was familiar with the system, possibly more so than my coworkers, so with 70% of effort I could meet the requirements, so I can spend more time helping kids

How about Macq? Hours are short but I often decide to work on weekends. I dare not leave earlier because I feel guilty that I haven’t made enough progress on my projects.

I feel the stress of helping kids with studies would /resonate/ (“conflict” is the wrong word) with the stress of stigma/PIP, and  create a highly amplified response, bigger than each stressor alone could produce. I would feel like a candle burning from both ends .. insufficient energy and would be forced to consider tough sacrifices.

I think Mvea team would be much better as Josh is very tolerant and forgiving.

Commute — how important is it? I now feel commute is insignificant compared to coworker benchmarking or PIP

likability n unusual habits #Kyle

I felt simultaneously intrigued and enlightened by your comment (also echoed by previous colleagues) about my uncommon habits, behavior, mannerism… When we discussed it, I decided not to ask for specific examples, but I assumed these are relevant

  • Wearing helmet when walking in
  • One barefoot on the rolling cabinet when using standing desk
  • Eating my food on a tray
  • Taking note in every meeting with a post-it pad rather than a notebook
  • Unshaven, or uncombed hair
  • Carrying a big camping backpack every day, as I described to you
  • Declining to attend any drink party, except the last party before I resign

These habits often draw unwanted attention. Since my late 20’s, I have made it a point to try and minimize these behaviors, but only if I’m aware of it. The helmet effect was only revealed to me by your comment.

Q: are these “features” or “defects”. The conventional wisdom seems to say these are defects because they are disliked by other people around.

I actually like people with these “features”. Rough around the edges, these people are usually geeks, nerds or mad scientists, but occasionally a manager in some team. Due to these unusual habits, some of these individuals have a disarming demeanor, others uptight and stern. Common theme among them – unusual “features”.

In contrast, across my past workplaces and beyond my immediate teams, about half the coworkers are well-polished with no unusual mannerism. A lot of times I don’t feel very close to them, as if there’s a mask between us. Semiconsciously I feel they don’t let their hair down easily, less spontaneous, not my type. A small subset of these coworkers can be described as cautious, even secretive, even territorial. In my subconscious, I tend to assume they show a sense of insecurity and are too afraid of losing face.

Across my past workplaces and beyond my immediate teams, most of the coworkers I have liked most are always the less well-polished.

My father is the well-polished type (but very much a nerd); my mom and sister are mavericks. Each of them is liked by some people, disliked by some people. I chose to follow my mother’s style, though I listen more to my father. Decades ago, I might have wanted to follow my father’s style, but I don’t have the skills and capabilities.

https://bintanvictor.wordpress.com/2011/02/28/likability-vs-technical-caliber/ is a blog post I wrote many years ago.

tech design “debate” with mgr

Some pointers from Rahul and other colleagues

  • [GS] pick your battle
  • manager will be the one holding the baby after you leave the team.
  • I feel I need to pay attention to the para-linguistics, and not focus solely on the technical side
  • I tend to hold strong views on design question that aren’t really major. I tend to argue and hold my ground even when it’s really a minor design decision. I appear stubborn and argumentative when I suspect the decision makers have not fully understood my points. Once I see that manager completely understands my arguments, I would stop pushing.
  • I feel i should put a limit on how much time I’m “costing” my mgr. After mgr has spent, say, 10 minutes listening to my points, I should probably “give up”.
  • [MS] Mgr probably hopes that I accept the collective decision and be “happy”, not reluctantly ..
  • [MS] need to avoid giving the impression that I have made up my mind about which design is best and only here to persuade.
  • [MS] need to avoid giving the impression that I’m not really open to new input
  • [MS] try to show unbiased .. without a favorite, even though my proposal is clearly my favorite
  • I hope to strike a balance between striving for a better design, and minimizing conflict
  • Try to detach the egos from the competing designs

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

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

hobbies generating +ve 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:)


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 ….”.

avoid conflicts with colleagues at all costs

Remember the theory about team forming , Storming, norming, conforming — Sounds like storming is healthy and necessary. I don't buy it.

“we encourage open debate” — bullshit. Many team members don't like those who oppose them and make their life difficult. As a manager I might encourage it rather than let team members fight private battles. I feel the debate is all about personal convenience. Who cares about system or user or team's long term healthy?

healthy debate in a team — bullshit

Even if 2 fellow developers know each other well, their tolerance for each other can be surprisingly fragile beneath the surface. If one of them shows just a little bit disrespect, relationship could unravel.

I guess if you avoid conflicts you may become a pushover. Well, pick your battle.

stay hands-on in financial IT

Better stay hands-on in financial IT, whether you come back to US or stay in S’pore long term. In Singapore, most hands-on developer jobs are less ideal (for older guys) than management jobs. Majority (above 70%) of my Singapore peers of my age group try to build a career path away from hands-on. Among the other 30%, some try to stay as hands-on architects or hands-on tech leads. If we were to stay in S’pore, such roles are ok till age 45. In the US, that age limit seems to be 55. Big question is whether you could become and survive as a hands-off manager. I think Yang tried but he still relies heavily on his tech skill. My competitive strengths (if any) in management roles are

* attention to detail
* reasonably good domain knowledge
* good rapport with some developers
* experience working overseas — many finance projects are global in nature

car racing while holding coffee

I now recall that my manager (Yang?) mentioned (in my first performance review?) that I had a tendency to be tense and look worried, and improved a year later. Now I slowly understand why.

Now I think many people in finance IT have a lower standard on test “coverage”, bugs, code consistency, code smell…

For a few years in GS I felt like a heart surgeon — any (avoidable) logical bug would cost lives, and put me to jail for negligence of professional duty. Finance app development is like car racing while holding a cup of coffee. I was too scared of spillage but still had to drive as fast as others – so tense!

Now I know many colleagues design code less rigorously than I feel done elsewhere, and cover only the realistic use cases. If input is unexpected or erroneous, then damn it — “undefined behaviour”. That’s what I see in some quant library too. Subtle errors could sometimes spread like cancer undetected.

We relied on recon or other system’s validation to detect (preventable) bad data created by our engine.
Rather than “stop error propagation at the earliest”, we rely on downstreams.

Another reason — GS was my first job on Wall St. I struggled to break into Wall St and I didn’t want to be inadequate and lose self-confidence.

#1 essential communication skill #in office

Whenever a finance IT job spec says “communication skill” or “communicator”, it could mean several things
– can understand business users
– can understand requirements
– can write (non-trivial) email
– can write reports
– can present

But I feel the most important criteria is — articulation.

I don’t know for sure, but i feel most people can do a good enough job of understanding users or requirements, but the level of articulation varies among developers.

I guess outside US and UK, some developers have problem with English.

[11] 4 career(survival)struggles for trading sys developers

Update: now I feel the top 2 survival struggles for me have been techIV vs localSys. I had real pains and set-backs with localSys , figure-things-out, and GTD etc but I am extremely lucky that my techIV advantage is __BIGGER__ than my localSys disadvantage.

Focus here is the trading sys hands-on developer’s career planning. Actually all the stressors here are mild compared to those listed in ## 3 heaviest job stressors

Struggle1: compete for jobs — Without strategies, one can easily get out-shined. The older, the harder. Often the hardest and the one struggle that counts. Recall our 2011-2012 job search… For many the biggest obstacle is CV, while for others it’s IV.

Struggle1b: overcome the “relevant experience” obstacle on the CV beauty contest. No one has track record in every major area. .

Struggle2: survive first 12~24 months — Statistically, most Veterans do survive but it can be a struggle for some. Banks pay 200% for a battle-tested veteran in order to get-things-done quickly. Timeline can be extremely demanding and pushing the human limit. Long hours. Can affect health, stress on everything including family. I was told developers in Asia face additional challenges.

Struggle2b: gain insight, create truly superior designs, add long term value — in addition to get-things-done. Not necessary for survival, but fulfills the promise of an “elite” expert developer. Caliber and Differentiation — Sets you apart on the job.

Struggle3: stay marketable long term — either in this or in another job market.

Struggle4: move up. Statistically, I guess most developers move into leadership roles but it doesn’t always come to you automatically.

GS xp: 1)decent design 2)faster n faster turnaround

In my first 12 months at GS, I would work hard on a feature, complete in
a day then proudly present to my team lead, only to hear from him “good
work, but why did it take so long? So and so could have done it in 2

This is just one of those awakening moments that slowly (yes slowly)
made it clear to me that my TL wanted 1) decent design 2) faster and
faster turnaround.

##1 week in ML — stay marketable and employable in financial IT

(another blog post)

Problem — in any bank, a contractor or employee at any age could lose job due to many reasons – economy, new boss…
Problem — too many young developers join the job market every year, often from overseas
Problem — we aren’t getting younger 🙂
Problem — waves of new technology

If anyone doesn’t feel the need to worry about it, i feel that’s unwise. One of my strategies to survive is focus on old and core technical topics –

* threading. Wall street always likes threading, even if their system doesn’t use threading
* data structures – java collections, STL, trees, pointers, basic arrays and basic strings (both outdated but extremely relevant)
* OO – static vs non-static, HASA vs ISA, abstract, constructors/destructors, proxy
* DB table + data model design
* DB tuning

Other areas I like
– memory mgmt
– messaging
– unix
– sockets

These technologies didn’t change for the past 10 years, except some new GC algorithms.

other sound byte reminders — empathy, attitude..

2012 – make people feel comfortable with you
2011 – imagine most people’s average antenna is much longer
2011 – Identify your eccentricities and unlearn — conform. Shift midpoint of your spectrum of normalcy.
2010 – Make your manager look good
2004 – “Shrink” and “Be invisible
2006 – Identify role models and imitate
2005 – Assume other people are potentially intolerant, cynical, over-sensitive, fragile, inferiority-stricken, and won’t give me the benefit of doubt
2000 – Focus the next 14 days on making someone truly happy

Seek weekly/monthly feedback — GS career advice
empathy, protocol, etiquette
Be a “teammate” rather than a mere co-worker
Be open to bitter medicines, hard-to-swallow medicines

Boss is less reliable a protection than your own survival skills

On a perm job, i can tell mgr my family’s need for job security and seek monthly feedback to avoid layoff. But If a new mgr takes over or profit declines, you can’t control much of anything. This pattern is ruthlessly, mercilessly universal.

Your knowledge and track record might be less portable than something like a citizenship, GC, a degree.

Boss and employer are unreliable but investing-in-yourself may affect your performance on the job.

likability vs technical caliber

Q: Out of 10 colleagues in your team, suppose “Beth” is the 2rd most likable and “Yen” the 2nd least likable. How serious is the gap in their likability? Is Yen really that unpopular?

Perhaps Not. If you rank the 10 people in your own team, the 2nd least likable person (the “Yen” in my illustration) is probably not bad. Out of 10 colleagues, it’s rare to find a single person clearly nasty, or unpleasant. You may find the 6th through the 10th are all reasonable teammates and you have a hard time ranking them (but how about at a time of bonus/layoff ? ) If you look at the last ranked colleague (, perhaps he has a strong personality/self-centeredness, or she’s always too busy to help you when you need her, or she forgets/ignores your requests, or he is a bit aloof and cocky and not that warm, or she’s too loud, or he’s too nice with the opposite sex, or she’s working too hard and makes you look lazy, or he has less humor than others …

(By the way, for focus and clarity, i will disregard the important fact that any measurement used in such ranking is extremely vague. )

Another ambiguity with likability is, the colleague you rank in the 2nd half may be my favorite types of personality. Clearly, we should both remove personal “恩怨” — someone who helped me a lot i may not like, but someone who made me a lot of trouble i may find quite amicable and fun to be around.

Another ambiguity is cultural boundary. The “nice” personality in one culture is usually considered polite and welcome (probably not charming/endearing) in another, but some 2nd-half kind of professional guy in India is quite possibly viewed with admiration and attractiveness by some Europeans, for example. Note there are infinite types of 2nd-half personalities!

Another ambiguity — I may agree with you this guy is nice and polite, but in a secret ballot I just won’t put him in the first half of likability. Nevertheless I may elect someone not so nice because she accepts ME better and makes ME comfortable. Likability is something personal to ME, just like clothing.

In a twist beyond explanation, I may never invite the nicest colleague for lunch (perhaps he’s too perfect and way above me), but I do share lunch with a lot of colleagues less than “perfectly likable” — I call it rapport.

Likability becomes serious at review/promotion/bonus/layoff time but i think only the managers’ view counts.
It becomes serious when — you try to transfer internally.
It becomes serious when — you are seen as a go-to person, a helpful teammate — reputation. People would mention your name when they need or received (non-technical) help.
It becomes serious when — you need a massive help from someone.
It becomes serious when — you organize an event.
It becomes serious when — you ask people for a character reference.
If a colleague confides in you, that’s a sign of your likability. Does it buy you anything?

Now consider technical caliber of engineers. The effectiveness, personal contribution and value-add of the 2nd decile vs 2nd last decile is more significant and visible. The difference can be objectively assessed. A mediocre engineer vs an insightful or fast-learning or quality-conscious or clear-thinking or systematic engineer — real difference. It shows in the work.

That partly explains why the very nice people I know often make slow progress professionally, but “mad scientists” often move up on their strength of technical caliber. My view is biased. Unlike me, many colleagues believe it’s more important who you know than what you know.

How about business analysts, accountants, professional traders, researchers and salespeople?

[16] keep interviewing; leadership track record #XR


I feel someone like us might work towards 2 goals simultaneously —
1) I like your tip on “keep interviewing” so as to keep ourselves marketable. Aim for 4 interviews a year?
2) move up in some wall street firm. Perhaps more achievable by job-hopping.

More developers seem to follow the 2nd goal than the 1st goal. (Doesn’t necessarily mean 1st goal is less practical.) Perhaps such a corporate guy is an ostrich hiding her head in the sand, or a villager building a home below the huge Huang-He levee, where river bed is above her roof level

My wife doesn’t understand why I keep interviewing. She feels I should focus on my job and try to meet manager’s expectation.

I agree promotion is primarily decided by immediate manager. Still, some leadership track record and deliverable is often needed. Manager could give you such a project (as happened to me in 2009), or you might be lucky to get such an opportunity, which might happen to a consultant. If you delivery but don’t get promotion, you could change job (internally or quit) to move up.

Sometimes I like the opportunity to coordinate a complex joint effort with users and external teams. I did it in GS and quickly earned some trust and reputation. If you happen to know a system better than others, then you could play that role — Leadership track record in the simplest form.

Actually this track record might be more _visible_ than leading a team of developers on a small implementation. Managers, users and other teams may not really appreciate the challenges of implementations, but if they participate in your “joint effort” they sure understand its complexity. It’s probably unfair that some people do a bit but get lots of visibility; others do a lot but behind the scenes.

c++^perl zbs insights: vastly different values

Looking at my blog posts on c++ vs perl, the value of my insights in these 2 languages are very different.

* c/c++ is the foundation underneath java, c#, OS, DB and most infrastructure software. perl is something most systems can make do without
* c++ performance is still the envy of most languages in the context of many high-value systems
* compared to c++, perl and php are niche languages, even if ranked in the top 10 languages
* there’s a large following and corporate endorsement for any popular language like ruby, groovy, pike, LISP, Tcl, but it doesn’t mean these are as important as c# or c++. Be critical. Be comparative. Be objective. Take a perspective.
* If you look at wall street salary, some perl or mainframe jobs could pay $100/hour, but be very critical and look beyond short term.

##better stay in front office trading@@

After I told you “better stay in trading”, I came up with a few more “predictions” affecting Wall St developer salary.

* c++ will become LESS used. I hope not much.
* c# will become more widely used. Salary will remain high.
* multi threading will become more important. Salary will remain high.
* DB will continue to be widely used, often indispensable, even though distributed caching may look like an alternative. DB expertise will continue to fetch good salary but is not the most highly valued trading system expertise.
* will FIX and connectivity work become more important? Probably yes. See next prediction.
* trading volume will increase for many asset classes, partly because of emerging markets and technological advance.
* Front office will continue to be as important if not more important than back office. I believe for 10 or 20 years front office has been more important because traders are the profit (and loss;-) center. FO salary will remain high if not not higher than middle/back office.
* Will market risk (not FO) become more important? Not sure
* will high frequency trading become more widespread? Not sure
* will quant modeling become more important? Not sure

##java survival skills in a trading system@@

* java/javac command line options
* null pointer prevention
* familiar with ide, esp. (remote) debugger
* familiar with logging tools/techniques to simplify logging to the extreme
** add logging without impacting existing code.
** tracing proxies?
* lots of asserts
* jconsole* get compiler to help prevent potential issues
* memory profiler?
* thread dump analysis
* sound concurrent architecture (high-level) to(low-level) idioms
* spring

Other survival skills/toolkit
* cvs familiarity
* lsof, tcpdump
* core dump analysis
* system memory investigation? never seen such a need
* unix scripting? probably
* vi, find, grep…

web skillset to keep our head above water

Outside trading domain, web (including spring MVC, dotnet, PHP, SOAP, ajax) is the mainstream technology. If we want to easily find a job in S’pore or US or China, then invest in web skillset.

Some Recruiters in trading are a bit arrogant. They don’t want to see web skillset on the CV.

I agree that at present (Jun 2010) most core trading components don’t use web, due to performance considerations.

By the way, more developers now are versatile in both java and dotnet. I think soon lots of resumes will start talking about “5 years java, 5 years dotnet, x years oracle, x years multithreading…” I was seen as a weak candidate for many years on the Singapore market because I had limited Oracle or Java experience.

how would i make a living if i can’t find jobs in IT@@

In one of my Toastmasters’ practices, I asked the audience this same question — “How would you make a living if you can’t find a job in your current industry? You could assume the industry declines considerably (outsourcing), too many new comers competing for dwindling jobs, and your family or health doesn’t allow you to continue in this line.” Here are some of my options:

* librarian
* Life guard, security guard
* assistant restaurant manager, overseeing a bunch of young staff
* work in and then run a small cleaning company
* run a maid agency, or baby-sitter agency
* run a small franchise supermarket, perhaps as a joint investor, but this takes minimum $5K (?) each head. This amount is quite a lot if i am in a dire situation — can’t find job in IT.
* Elderly’s nursing home. Growing demands in greying S’pore.
* cold-calling — perhaps decent investment products from well-known banks. I did cold calling for real and i think i have what it takes.

* newspaper reporter, editor
* ditto for a magazine
* ditto for a tech news site, but not the Web Master (WM is IT).

* Nonprofits do hire people. i think i can help in a few ways including fund-raising (no talent) and hands-on work
~> buddhist organizations do hire people
~> volunteer organizer, a paid job to organize volunteers. I doubt i have the talent but i do have some suitable qualities.

* learn and practice accounting. Boring but i think i have a good foundation.
~> If accountant is hard, then book-keeping.

* private tutor for secondary school students
* teach (IT or something other than IT) in a training school
* ditto in a gov school
* get a master’s or PHD and do research/teaching.. Physics, Electronics, Math?
* lab technician in University

how I estimate workload #XR

Hi XR,

There’s a lot of theory and many book chapters and courses on app development estimation. I don’t know how managers in my department does it. I’m sure these factors below affect their estimations.

* the right way of solving a problem can shorten a 2-day analysis/discussion to 2 hours, provided someone points out the correct way in the beginning. In our bigger department (100+ developers), many managers make estimates assuming each developer knows the standard (not always best) solutions from the onset. If I am new i could spend hours and hours trying something wrong.

* as in your struts form-validation example, a good framework/design can reduce a 1-month job to 1-week.

* tool — the right software tool can reduce a 3-hour job to 30-minutes. Example — I once mentioned to you testing tools. Also consider automated regression testing.

* A common complaint in my department (100+ developers) — a poorly documented system can turn a 2-day learning curve into a week.

* I suspect my colleagues do fewer test cases than i do, given the same system requirement. This is partly because they are confident and familiar with the system. This could mean 30% less effort over the entire project.

office protocol – don’t just imitate a colleague

For a guy like me, lacking “commonsense” in communication protocols, the obvious advice below isn’t obvious — it’s basic — Don’t imitate a role model blindly.

A role model with 4+ years spent in the current company can freely mention (generally, without reference to any individual) changing job, but if you are less than a year old here, it’s a taboo topic, like the name of the reining Chinese emperor (in ancient times).

Even if in a group every colleague seems to freely talk about this sensitive topic, I would say safety-first — a new employee should avoid the risk unless she doesn’t care about negative consequences.

Someone well-established in the office can openly criticize the company. She can compare the current company with competing companies, and few would question her loyalty. She can suggest many “improvements” but if I were to do the same, many would take it as lecturing and GS-superiority.
Americans like joking. Some may make jokes of a colleague’s weight or marriage and it may seem to be an OK joke, but can I do the same? Absolutely not unless that person is my best friend.

As a consultant, I was told to dress in long sleeve shirts everyday. Then I saw some employees dress in T-shirts. Should I follow? If I do, some may feel I’m not showing enough respect. I should not over-dress either, coming in business suits everyday. I guess I should imitate other consultants.

feel good +! gr8humor ]ff

) First off, jokes don’t cross cultures
) Some colleagues found me laughable. In contrast, Some workers are widely considered no-fun, too serious …. Clinically “sick”
) I have always felt like a simple, almost naive person on most teams
) sometimes I can feel and look relaxed
) xp: with some colleagues I could enjoy great, hearty jokes — Philippe, Tom Wei, Sreeni, Ansari, Guru, Sashi, Teck Wei, Andrew, tanko, Zhang Jun, Zhang Jiong

avoid hands-on coding@@

It’s easy to fall into the trap — avoid learning hard-core development technologies when passing age 30. Many ambitious young men do that. They tend to think coding has no shelf-life.

I feel good about myself still learning hardcore coding.

I still believe my experience with enterprise app challenges (tx,cluster,perf,…) has value in 20 years.

I still believe tech zbs is more solid than PM skill. I could do a good enough PM job even without 2 years experience.