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
Advertisements

wfh – j4^concerns

I trust XR’s experience…

  1. 😦 Productivity is likely (XR: inevitably) affected … increasing the deadline stress.
  2. 🙂 saves commute time, can be used on coding drill or with family.
  3. 😦 I might feel isolated, lack of support … though I do come into office quite often. I think WFH workers need to be more independent.

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

establish tech stronghold(GTD+nlg)]each team

Note – focus is job performance, not IV.

To survive in a team,need unique technical specialty in a key area.

With the possible exception of the Citi Muni team, I have not seen a banking IT team to tolerate a “dead weight” guy. To do reasonably well in any financial IT team, I often need some “hard” strength (like an subject matter expertise), not just soft skill. If within your team you have a unique technical strength in a complex and important sub-system, then you can “name your price”, and you are kind of irreplaceable. Perhaps a go-to person. Some team members don’t have any expertise but survive on strong relationships. I’m unable to do that. In the past teams, I think many team members have such a strength. If I don’t have it, my position would be less established, less solid.

  • 😦 😦 stirt? Worst experience. Was good at the insignificant preferences framework; canceled trades
  • 😦 GS? Uncomfortable position. My Perl was not top notch. My java was below Yang. I became good at Error Memos (EOS) and trailers/upfronts
  • 🙂 OC? was good at Bloomberg adapter and Guardian builtin web server to show the log files
  • 🙂 🙂 95 Green? My DB design was convincing to Ravi. My wait-notify based design was pretty hard to match.
  • 🙂 Barc? FMD, fmath
  • 😦 Macquarie? In the quant team, whatever I accomplish seems trivial to manager, since he’s too strong. I’m seen as very slow on small tasks.

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

##types@Work 2 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?

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:)

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

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.

[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
hours.”

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.

professional consultants — tone down personal taste

Respect your client’s preferences and personal tastes. They will inherit and live with the code you leave behind. If they don’t feel comfortable with some part (even if it works perfectly) they have a legitimate reason to change it to something more manageable.

You are not owner of that code. You are writing it for him/her to own.

Imagine you are a carpenter making a dressing table for a client. Is your personal taste or client’s taste more important?

In fast-paced finance IT, sometimes you can be forgiven to adopt your personal favorite choice (rather than client’s favorite) to help you get things done fast — since you are the coder. I feel in some contexts time-to-market is still the paramount consideration.

##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)
* SQL
* 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.

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, 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 think carefully. If you rank the 10 people in your own team, the 2nd least likable person (the “Yen” in your team) is probably not bad. Out of 10 colleagues, it’s rare to find a single person clearly “nasty”. You may find the 6th through the 10th are all reasonable teammates and you have a hard time ranking them, (but consider bonus/layoff season). If you look at the last ranking 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 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. No objective measurement, except surveys.)

Another ambiguity with likability is, the colleague you rank in the 2nd half may be my favorite type of personality. Clearly, we should both remove personal “en1yuan2” — 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 (but probably not charming/endearing) in another, but some 2nd-half kind of professional guy in China is quite possibly viewed with admiration and attraction by some Americans, 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 time but i think only the manager’s (+ a few other 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 (multiple) 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? You bet.

Now consider technical caliber of engineers. The effectiveness, personal contribution and value-add of the 2nd decile vs 2nd last decile is somewhat 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 the strength of technical caliber. My view is biased. I know many who believe it’s more important who you know than what you know. That’s a question for the next blog.

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

keep interviewing; leadership track record #le2XR

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.