程序員技術大牛升職後不編程是否是有一種浪費？

01-04

大牛們往往具有豐富的編程經驗和技術知識，但從他們的職業發展考慮，總會升職為項目經理、架構師這種職位，不會直接參与編程工作。這時，之前辛辛苦苦積累的技術知識是不是一種浪費？
我明白這些技術在工作中多少還是有用的，但作用明顯不如項目管理知識、軟體架構知識等。升職便意味著改變了自己的知識領域，也是背叛了自己的興趣。對編程本身有興趣的人升不了職，對管理或架構感興趣的人沒有機會，是不是只有朝三暮四、什麼賺錢幹什麼的人才能生存？

又是一個沒有聽說過David Cutler的人

是真大牛，就不浪費。

一個程序員技術大牛，編程牛隻是表象，實質是牛在思想、牛在思維方式、牛在學習能力。

參與規劃、參與決策，價值更大；

傳授技能和思想給團隊，讓團隊執行，讓團隊進步，收益更多。

# =================================

別只開會，別只編程，也別只上班，以任何形式創業、創造、創作，對於能力者來說，都會是快樂事。

長江後浪推前浪。coder還是年輕的好。一個好的指導者帶著年輕人能幹好很多事情。

還有，千萬別讓不懂技術的坐在決策技術路線的位置上，這樣你好我好大家好。優秀的技術人員升職加薪是對團隊負責。

如果不升職，繼續編程，才是巨大的浪費

如果你不能升職，只能繼續編程，那就是巨大的悲劇！

你說的這個只是一個方向，大公司都有兩個方向走的，一個是走管理路線，就是你說的那種，一個是繼續走技術路線，繼續參與編程開發或者技術研究

拿騰訊來說，不少工程師是走的技術路線的，不是所有人都想走管理路線，那麼這些工程師升職後，仍然走在前面繼續做需求或者退後後面做技術研究，又或者開課傳道受業，不會受到束縛，職級仍然繼續升升升。有的走了管理路線，做了組長或者leader。

另外補充一點，我們公司對於任何高級工程師的要求裡面，都有提到一點，那就是除了平時自己技術提升之外，還要給團隊同事進行引導，帶領團隊整體的技術提升，也就是說，達到這種層次的同事，平時做的事情也不僅是做需求這麼簡單了

每個人的追求不同。

這種情況很普遍，最關鍵的還是要看這位大牛本身的素質，以及公司管理在技術人員的角色轉變這件事上下多大功夫。

從個人素質來看，一個人的本性是很難改變的，技術人員普遍的問題並不是缺乏管理技能，而是同理心和溝通技巧，另外更重要的就是轉變自己所必須的慾望，國內因為環境原因，很多技術大牛走上管理崗位是形勢所迫或者是安全感的缺乏，而不是真正自己所想。如果一個技術人員能夠首先解決自己的問題，並且有強烈的意願去做管理者，學習管理技能和發揮自己的技術優勢並不是難事。

從公司角度來看，將一個技術大牛直接扔到管理崗位上是非常不負責任的，代價也很高，最壞的情況會直接毀掉一個優秀的技術人才。好的做法是產品負責制，而不是技術負責制，另外將項目管理、進度把控等管理瑣事，分離到其他人或者成熟的流程上。這方面，更高一層的管理者需要一定的管理智慧，因人而異，合理放權以及給予支持，才能充分發揮技術大牛的威力

資深程序員是團隊中最強大的生產力，但往往被不合理的工作安排浪費掉。

因此作為一個團隊的技術的「頭」，必須要有明確清晰的認識，把主要的事務性工作剝離出來。

並且放棄大量的管理「權力」，以提高團隊開發質量和效率為最主要的目標去安排自己的工作。

一般來說技術總監其實會被要求做事實上是2個職位的工作：主程、項目經理（技術化）

因此必須明確此兩個職位的工作任務分割。然後把項目經理的工作，安排給另外一個人做，當然其職稱可能同樣也得叫「技術總監」或「主程」，總之聽起來越牛X越好。

而真正的主程（技術總監）則應該投身於盡量多的技術工作中。而最重要的工作則是開發——生產代碼和文檔。

主程的工作：

一、開發

從來沒有一個資深的外科醫生會放下手術刀，而轉到手術室外面指手畫腳。一個資深的程序員也不應該離開代碼和文檔的編寫，而只是做做架構圖。作為對一個複雜系統的負責人，必須親手領導和參與建造，才能有足夠的能力去負擔起這個責任。因此需要至少使用60%的時間來參與開發的工作，並且建議從一開始上班就開始，雖然早上的效率很低，但是跟任何艱巨工作都一樣：萬事開頭難。在你好不容易等待電腦慢吞吞的打開了所有的IDE、需求文檔、參考資料、工作計劃這堆要命的東西之後，你就邁出了最重要的一步，你會發現你不在需要在網上看微博和聊QQ來提振開始工作的激情，而會被某一個優化代碼的靈感而激勵，或者被一個複雜而有趣的問題所吸引，從而更快的能投入到開發中。堅持打開電腦做的第一件事是打開IDE軟體，是這一切最重要的一步。

開發的工作內容包括有：

1提出非功能性需求

一般來說功能需求總是讓開發人員焦頭爛額的主要原因。但是實際上很多項目死在發布之後，卻是因為性能、產品質量、擴展性、二次開發效率等非功能性需求沒認真去解決而導致的。主程作為經驗最豐富的成員，必須要利用自己曾經的經驗和教訓（在這裡教訓往往比經驗重要），提出那些自己折騰自己的「非功能性需求」，來保障整個項目在發布後不會轟然倒塌。這是個吃力不討好的工作，因為老闆和客戶往往只會抱怨技術人員在玩弄把戲，騙取更多的資源或者杞人憂天。如何說服這些傢伙也許不是主程的工作，但是主程必須要以高度的責任心把問題放到檯面上來。溝通的工作也許讓項目經理去做會更好，他們有一整套如何威逼利誘老闆和客戶的戲法。

2設計和修正軟體架構

軟體架構設計至關重要，而且工作繁重。不畫圖紙就敢開工的技術人員要麼是天才要麼是笨蛋。對於團隊來說，架構在分工合作、避免風險、提高質量等多個方面有無可替代的作用。架構要避免成為空洞的文檔，最重要的一步是有人來掌控和實施。而主程主持設計和修正的架構，並且親手實施，讓團隊中的腹誹之徒完全無法避開，否則代碼將無法運行！所謂設計和修正架構，並不意味所有的文檔應該一個人寫，而是指這個架構的每個環節，都是經過主程決策同意的。當然最好這些文檔能盡量由他撰寫，對於「菜鳥」團隊來說，輸出這種文檔本身就意味著「權勢」，有助於主程建立個人威信——這種看起來有點骯髒的「政治」東西，在避免團隊內無止境的扯皮，以及穩定那些隨時準備跳槽的成員來說，都是相當實用的。

3難點代碼（關鍵需求）的開發

主程必須寫代碼，寫那些大家都認為風險大的代碼。有的系統對於性能要求很高，他就必須去完成容易出性能問題的部分，比如IO操作或者設計資料庫索引。有些系統的需求非常飄忽，他就要去想辦法完成框架代碼或者腳本引擎，以便眾多小弟可以跟著產品人員疲於奔命。這種工作內容會讓主程不必完全的讀過所有代碼，而能牢牢的「掌握」代碼，以免團隊成員甩耙子的時候能充當備胎。因為融入團隊的代碼開發，也是一個讓架構設計從日常工作中真正控制系統的工作。而且主程代碼通常會被別人接觸，能直接教育其他團隊成員，同時也能建立——威信。

4救火和殺蟲

這個工作其實和代碼開發是一致的，如果沒有平日的開發，通常緊急問題的解決也是比較難處理的。但是這個也有一個調試技巧的要求，比如要求會使用各種診斷工具。這些工具一般的開發人員可能會比較少使用。找問題的過程本身也可以提高團隊其他人的技術水平。

二、培訓

培訓的工作應該佔用30%左右的工作時間。培訓是穩定團隊人員最重要的手段。也是提高團隊開發效率最有效的手段。工具、過程、制度、獎懲，這些都代替不了程序員一行行的去寫代碼，最直接的方法是讓他們做的更快更好，這些需要經驗和知識的積累。

1代碼審查

關於代碼審查，有太多的論述。但是代碼審查還是一種「強迫」推行某種風格或者技巧的手段，這是最真實的「控制」系統的手段。也是推廣知識和經驗最直接的手段。一個人寫的代碼通常應對的問題不會特別「廣泛」，因此只要審查其中一部分代碼，就能給大部分別的代碼帶來好處。

2技術方案評審

什麼事情應該寫一個技術方案，然後進行評審，這是一個關鍵的問題。一般認為開發時間在2周以上的單項工作應該先做個方案。往往技術方案是系統架構的完善和補充，或者是挑戰。所以主程的參與是非常必要的。但是要注意不需要去做的太瑣碎，而是要提煉出「關鍵」的需求和「關鍵」的解決方案進行評審，而這些「關鍵」往往不是功能，而是質量上的需求，如這個系統的擴展性，是否能方便後續開發等等。也有可能在這些會議上會發生爭吵，但是決策人是主程的地位是不容動搖的。君子和而不同，每個程序員都可以擁有自己的看法，但是代碼必須能按方案運行起來，主程必須經常申明這點。

3學習與講座

如果團隊碰到問題，沒有新的方法和技術去解決，是不會提高開發效率的。就好像你用牛來耕地，不管用什麼管理方法，都不會趕上機械化的速度。而主程承擔著不斷突破自己的技術上限，介紹和推動團隊使用更新的技術來解決問題的責任。抱殘守缺，思想僵化，最後會被團隊成員所拋棄，而且也會讓團隊的效能落後於業界，最後直接影響產品的生死。每年學一門新語言，這個說法可能有點激進，但是這也是作為程序員應該有的激情。

三、管理

管理等於權勢？管理等於溝通？管理等於文山會海？多年專業訓練出來的技術人員如何去做管理？

管理的目標是提高績效，如果和這個目標無關，而只是和「管理者」這個頭銜有關的事情，最好丟給別人去做，包括那個頭銜。管理主要手段是創新：想出新的方法去解決問題，而不是繁雜的事務性工作！——一個專業秘書能比主程做的好一百倍。技術工作的創新，最主要還是在技術工作裡面，而不是跳出來說：做這個，做那個。

管理的事情如果超過10%的工作時間，等於說你更像一個項目經理而非主程。

1績效評定

以專業的意見來衡量別人的工作，這個負擔是無人能夠承擔的。這個工作往往是利益分配的一種手段。類似獎懲手段。這種管理方法已經不是新事物了。但是實際上技術人員對於績效往往持一定保留和曖昧的態度，因為這種事情難以很清晰的界定出來。需要判斷而非量度，才是績效的真正手段。如果一定要打分，一共兩項足夠了：進度、質量，5分制即可。更重要的事情是，告訴每個人主程的看法，告訴別人，怎樣做才是更好。或者告訴團隊，怎樣做才更有利於我們成功（發財、上市、贏得老闆和客戶……）——把目標清晰告訴團隊，發揮他們的主動性，是績效評定最重要的目標。

2需求評定

最讓技術人員頭疼的可能就是和客戶談判。這個事情實際上不應該讓技術人員來傷心，有項目經理就可以了。而需求評定更多的是可行性的討論。主程如果參加每個需求評定，他要三頭六臂也搞不定，正確的做法應該是具體開發的團隊人員參加，而主程在開會前給與自己的意見，或者會後聽取參與者的總結。——這是了解別人做什麼事的一個重要手段，但無需陷入太深，因為還有代碼評審和項目經理的幫忙。

3跨部門溝通

實在沒必要參加，能躲就躲，這是扯皮的天堂。讓項目經理去吧，他們的專業技巧能讓這些事情更加有效。只要回來後讓項目經理告訴你發生了什麼事情就可以了。

4進度審核和任務分派

又是一個很有「權勢」的工作，實際上團隊成員的情況大家都知道，決定誰應該做什麼事情並非需要很多時間去想的事情。所以大可以把方向性的意見告訴項目經理，讓他去做。很多優秀的開發者玩EXCELPROJECT之類的水平還不如只有一年工作經驗的秘書，別折騰自己了。

5面試

如果真想幫忙，準備一份有區分度的筆試題目吧。不靠譜的人太多，老闆可不是花錢請你和他們聊天的。讓項目經理去聊，不用擔心他們技術不強，再不夠，也會比大多數面試者要牛X。他們搞不定的人，就是應該僱傭的傢伙。畢業生招聘怎麼辦？只要看看他們課外活動是不是有搞些專業的事情就可以了，上進心比別的東西都重要，HR會比主程看的更准，相信我。

6各種會議

飯無好飯，會無好會，超過6個人的會議應該堅決抵制。如果你有一個程序等著你去寫，你一定無比痛恨這些會議，順應你的內心吧！上帝保佑你。

初心不重要，重要的是你想站著賺錢還是跪著，人家讓你幹什麼你就幹什麼，還是你想幹什麼就幹什麼。想好就行，反正我知道99%的國內程序員來做這個行業都是想通過技術轉管理的。沒見現在都說程序員干不過40了么。

順便普及下，架構師都是資深資深程序員，設計人員也是如此，你說的可能是外包會這樣。。呵呵。。高級軟體工程師都說不清並發包類元素的大有人在，架構師連字元編碼結構，浮點數構成都不知道，大有人在。

順便補句話，那行里的口頭語是，大學裡沒教，用不到啊，我媽說不用學那麼精，差不多就行

我做項目經理因為

1. 喜歡管理

2. 不喜歡編程

看，對面的姑娘貌美如花，就這麼單身著，是不是有點浪費。

沒這些技術積累，怎麼培養骨幹都不用說了，隨時隨地被被下面的人耍得像猴似的。

技術積累到一定程度，就需要思考怎麼把這些技術的影響更大化的發揮出來，寫不寫代碼只是一個方式，換個高度想想。

嗯對，戰場上最身先士卒最勇敢殺敵的士兵就不應該給他們當將軍，不然你想多浪費啊！

主要看他在其他方面的貢獻，比如架構，技術方向，流程，規範，團隊，產品等。

我還納悶醫院的大牛去升級當院長是不是浪費了！

即使技術大牛不編程了，做管理，也不浪費。如果不懂技術做管理，一個任務他都不知道工作量有多大，技術難度有多大，怎麼分配任務，怎麼控制進度。

我很久以前也是這麼認為，但是後面一些接觸以及去年看了阿里上市的多隆的介紹後，我才發現就寫代碼也可以有多牛B。

一個頂尖coder的作用和價值不比PM小，另外，技術背景有助於精細化管理，失去的編程價值可以被管理價值覆蓋即可。

成為技術大牛成為技術大牛，或許，就是為了升職以後可以不編程。

另外項目經理、架構師也是靠編程經驗和技術實力積累的，一個不合格的架構師或項目經理會讓底下的技術大牛抓狂。

謝邀。

我認為，技術大牛不去創業才是浪費。