As I discussed with Kyle, a worker’s sense of productivity is complex and subtle, far from objective. It’s influenced by many factors.
The sense of productivity is an important part of job satisfaction, sense of inadequacy + inferiority, duty ^ guilt, self-hate ^ compassion.
I tend to use this incredibly vague concept as a whip to beat myself up. I guess some managers (Mark, Venkat, Stirt) also use it on me…. harsh.
- It depends on the visible progress on project assignments. Projects are stuck frequently– like wheel-spinning. eg: StirtRisk projects were often stuck and I felt less productive. I had a short-n-sharp discussion with Rahul, who identified context-switching as the productivity killer
- It depends on visible impact on users — the #1 most visible sign of value of my output.
- Eg: RTS, 95G, mortgage commissions, Quest,
- proficiency in prod support has big impact. It is seen as low value, associated with ops team in Barc, 95G, Citi, but perceived as high value in GS
- It depends on localSys + understanding of user’s logical bubble. Those developer in close contact with users would have better gauge of which to-do (and which solution) scratches a big itch. 四两拨千金, 事半功倍.
- It depends on Perceived impact of my output relative to coworkers
- eg: outstanding in Barclays
- It depends on our personal (highly inaccurate) estimate of how many focused hours/day. If “visible” items unavailable, then this is my default basis.
- It depends on My vague perception of coworker productivity. Kyle felt the perception is not that vague.
- It depends on How early coworkers come and leave; Coworkers working-from-home. Note Many hiring managers say (honestly) that if an efficient worker can get things done in time, then boss doesn’t mind shorter hours or WFH.
- It depends on How much leisure time I see in coworkers’ day, including chitchats
- It depends on Role model set by manager. Eg: Saurabh often took Friday as a lite day.
- It depends on User’s feedback on my output, often in brief emails — RTS
- It depends on Coworker feedback on me – OC, Macq
- figure-out-by-self — is a controversial yardstick. In most places (Ashish) it is a top 5 sign of productivity, but in GS I was told to not waste time researching. My GS colleagues always ask each other and I had to.
[[The Art of Readable Code]] has tips on naming, early return (from functions), de-nesting, variable reduction, and many other topics…. Here are my own thoughts.
I said in another blog that “in early phrases (perhaps including go-live) of a ent SDLC, a practical priority is instrumentation.” Now I feel a 2nd practical priority is readability and traceability esp. for the purpose of live support. Here are a few unconventional suggestions that some authorities will undoubtedly frown upon.
Avoid cliche method names as they carry less information in the log. If a util function isn’t virtual but widely used, try to name it uniquely.
Put numbers in names — the less public but important class/function names. You don’t want other people outside your team to notice these unusual names, but names with embedded numbers are more unique and easier to spot.
Avoid function overloads (unavailable in C). They reduce traceability without adding value.
Log with individualized, colorful even outlandish words at strategic locations. More memorable and easier to spot in log.
Asserts – make them easy to use and encourage yourself to use them liberally. Convert comments to asserts.
If a variable (including a field) is edited from everywhere, then allow a single point of write access – choke point. This is more for live support than readability.
How do global variables fit in? If a Global is modified everywhere (no choke point), then it’s hard to understand its life cycle. I always try to go through a single point of write-access, but Globals are too accessible and too open, so the choke point is advisory and easily bypassed.
This is a frank, honest but personal observation/reflection of the reality I witnessed. We should always bear in mind how (in)dispensable we really are to the business.
+ Many wall st trading system development teams have no QA personnel so developers do that. I did that.
+ Many wall st trading system development teams have no BA, so the project lead or key developer do that. I did that.
+ Many wall st system development teams have no RTB (Run-The-Bank, as the opposite side from Build-The-Bank) support team, so developers do
that. I did that. RTB can probably handle major FO (front office) apps but a lot of apps aren’t in that league.
+ Each wall st trading system development team I have seen never has a hands-off architect. If there’s an architect this person is first a coder then an architect.
+ Some wall st trading system development teams have no need for a DBA or unix SA (system admin). Without going into specifics, much of the expertise isn’t needed before release to production if (not a big if) developers _can_ build their apps themselves. In rare cases developers need some tuning advice.See also http://bigblog.tanbin.com/2010/12/hands-off-manager-according-to-lego.html
– However, proj mgr is crucial, every time. Most wall st systems are interdependent and extremely quick turnaround, requiring non-trivial communication, coordination, estimation, monitoring. I feel half the time the key developers don’t play the PM role.
My Citi mgr divided my work into ProdSupport + Greenfield + BAU i.e. (strategic or quick) enhancements on current production codebase.
In ML, effort is divided into BAU 66% + 33% Greenfield
GS is 75-25
One of the hardest part in Greenfield is replicating BAU behavior. The closer we get to prod release, the more we rely on prod system knowledge. Those nitty-gritty BAU behaviors become necessary features and show stoppers.
I think recruiters generally see Greenfield as more attractive. More design involved. More experienced candidates required.
A friend said green field becomes stressful as release date approaches.
hi, Tan Bin
Varies Knowledge Module comes with Agent, base on the role, other than monitor OS itself, you can purchase and configure Knowledge Module to monitor applications/services running on it.
it is similar to Microsoft MOM. every new application come on, MS will develop Management pack to install and moitor it.