說說java程序員的工作、學習與績效

工作中,碰到一些這樣的例子,總有人提出疑問,為什么一個同事工作勤勉,完成了很多事情,季度績效評定很高,但晉升卻碰壁了。之前已經寫過一篇《技術晉升的評定與博弈》,基本就能解答這個問題。但隱藏在背后的更深層次的本質卻是:工作、學習與績效的關系。

  工作

  程序員的主要工作是:編程,產出代碼,完成需求,交付軟件系統。

  程序員按其工作技能和經驗,大體又分為三個階段:初、中、高級。三個級別的程序員的主要工作都是編程與產出代碼,產出代碼的數量也許相差不大,但產出代碼的屬性可能有明顯差別。

  在曾經的文章中提出過一個代碼屬性:資產與負債。由大量初級程序員產出的代碼并以此構建的軟件系統,如果最終能完成交付,那么很可能資產和負債性基本持平。這是很多早期創業公司的特點,因為缺乏資金和足夠的知名度,難以吸引到又多又好的中高級程序員加入。這樣的系統多屬于勉強滿足業務需要,看不出明顯的 bug,但一遇到特殊情況就容易宕機。整個系統雖然勉強能支撐公司運營,但其中欠下了大量的技術債,先活下來,未來再來慢慢還。

  若是完成了一個債務比資產還大的系統,會是個什么樣的情況呢?那這就是一個還存在明顯 bug 的系統,是基本無法完成交付和上線的。因此,現在主流都是先完成一個資產和負債剛好過平衡點的系統,發布上線,接受反饋,再快速迭代,在迭代中不斷地提升其資產性,降低其負債性。在 Facebook 的著名標語激勵下,奮力前行:Done is better than perfect(比完美更重要的是先完成)。

  而中高級相比初級程序員,就不僅僅是交付代碼,完成工作,還有后續的兩條:達成品質、優化效率。從初級向后兩級跨越的門檻就在于此,比較容易被卡在不斷地在完成工作,但卻沒有去反思,沉淀,迭代并改進,導致一直停留在了不斷的重復中。

  程序員的工作,以產出代碼為主,從初級到高級,代碼的負債屬性逐步降低,資產屬性不斷提升,并成為高品質的個人貢獻者。在這個層面上,還是 Facebook 的另一條標語足以說明問題:Code wins arguments(代碼贏得爭論)。

  學習

  學習,是唯一能讓你突破不斷循環怪圈的不二法門。

  程序員在攀登職場階梯的道路上,走過了高級,后面會有好些分叉路線。比如,轉到脫離技術的純管理崗或者技術管理崗。我以前寫過,技術主管或架構師某種意義上都屬于技術管理崗,不懂技術是做不了這兩個角色的?;蛘嘸絳刈派疃攘煊蜃?,成為細分領域專家。

  這后面哪條路適合你呢?你是隨大流,還是自己真得認真思考過?這是做選擇題。如果一生要工作三十多年,前十年你多在做解答題,解決一個又一個問題。那么在大約走過三分之一后,你就會開始做越來越多的選擇題。為什么呢?因為一開始可能都沒有太多選擇的機會。而做好選擇題,就需要大量的學習,還需要不斷的試錯。

  面對怎么選路的問題,我近年學習的收獲是這樣的:選擇走最適合實現個人價值的路。這就是我的基礎選擇價值觀。程序員的個人價值該怎么實現?該如何最大化?程序員作為個人貢獻者,產出的增長隨時間和經驗實際上連線性都不是,而是呈對數曲線的《兩種增長曲線》。到了一定時間必然面臨瓶頸,這就需要找到一個價值貢獻放大器。有人很幸運的編寫服務于數千萬或數億人的軟件服務,這是產品自帶的價值放大器。這樣同樣寫一份代碼,你的價值就是要比別人大很多。而轉管理者、主管或架構師,這些角色無非都是自帶杠桿因子的,所以也有價值放大作用。但個人能否適應得了這樣的角色轉換,又是另一回事了。

  現在稍具規模的中大型公司內部的職場階梯模型,我看基本都源自拉姆·查蘭的那本書《領導梯隊》。書里把人才潛能分成三種:熟練潛能、成長潛能、轉型潛能。原書文中對這三點做了詳細的特征描述(比較長),我簡單提煉下主要特點:

  • 熟練潛能:關注當前專業領域且十分熟練,但沒有顯示出在開發新能力上的努力,竭力維持現有技能。

  • 成長潛能:按需開發新能力,顯示出高于當前層級要求的其他技能(專業、管理、領導)。

  • 轉型潛能:持續有規律的開發新能力,追求跨層級的挑戰和機會,展現雄心壯志。

  人力資源管理中的高潛人才盤點,基本就來自這套模型,主要就是識別出這三類潛能人才?!甘熗非蹦堋咕褪嵌匝暗淖畹鴕?,在程序員這個技術日新月異的行業里,維持現有技能確實已經讓不少人感覺很竭力了。

  攀登的這條階梯,它從來不是筆直的。在每一個拐彎處,都應減速、思考、學習、進步。學習也常與錯誤相伴,查理·芒格說過:

  世界上不存在不犯錯誤的學習或行事方式,只是我們可以通過學習,比其他人少犯一些錯誤 —— 也能夠在犯了錯誤之后,更快地糾正錯誤。但既要過上富足的生活又不犯很多錯誤是不可能的。實際上,生活之所以如此,是為了讓你們能夠處理錯誤。

  績效

  績效,特別是程序員的績效,從來都是個謎《程序員的績效之謎》。

  一談績效,管理者就會說誰誰績效很好,你看加了很多班,做了很多事。之前說了程序員交付的軟件系統,如果說代碼的資產和負債屬性相當,大家可能會沒有直觀感覺。做個大家熟悉的類比,如果只是相當,這就像我們刷信用卡購買了一項產品或服務,滿足了當下的需求,贏得了時間,但將來這筆欠款是要還的,不還就會付出代價。但如果是資產遠大于負債,那就是刷了卡,后面卻不用還了的感覺,那應該是種暗爽的感覺。后者才叫績效好,但如何評估?謎。

  最近看劉潤的文章講到 KPI 管理,提到了一個考核微軟技術支持的辦法。感覺挺有意思,如果把它換成程序員的場景可能就是這樣一些關鍵指標:

  • A:需求難度系數,需求評審時架構師和程序員共同分析確定,達成共識

  • B:需求花費時間,越短越好,由程序員自己記錄

  • C:完成需求提交的代碼行數,越少也好,需要定制工具支持代碼和需求關聯的統計

  • D:完成需求數,越多越好

  • E:E = A x B x C x D 表示有效工作產出

  其中 A 難度系數基于團隊共識達成,因為大量的業務需求,其實很多難度近似。B 和 D 實際是兩個互相制衡的因素,本來用 1 小時完成的,你自己記錄成 10 分鐘,那么完成的總的數量就會變少。C 展現了代碼技術能力,完成同樣功能的代碼,資產性不變,越少的代碼行數越少負債。這樣當衡量有效工作產出(E)時,同樣的 E,A 和 D 大的技術能力更好。

  當然,這是一個簡化的理想模型,但現實中程序員的考核恐怕比這個模型更簡單粗暴。但它也指出了一個事實:晉升技術能力更好的人,他們解決更難的問題因而創造壁壘,產出更多的資產和更少的負債。而對于僅僅單一高績效的人,不適合用晉升來激勵,而應該用獎金來獎勵。 ...

  為什么業界喜歡三到五年的程序員?按一萬小時理論,三到五年接近或滿足了這個量的編程訓練,這個階段就是產出代碼的黃金時段,量大質優,而且各公司的“坑”(職位)也多。

來源:博客園

上一篇: 2017年13個不容錯過的Java項目

下一篇: JavaScript的API設計原則

分享到: 更多
500元 倍投方案 稳赚 澳门21点规则 幸运飞艇稳赚玩法 快速时时官网 安徽时时快三 麻将的玩法和规则 psv2000必玩游戏排行 通比牛牛的作弊器 后三组选计划软件下载 广东11选五计划软件哪个好 超神冠军五码计划 时时彩包胆计划技巧 mg助手 诺维奇 探球比分即时足球比分 老版本128棋牌