程序員如何管理

『壹』 程序員如何提高自己才不被淘汰

要想自己不被淘汰，不只是提高自己的程序員能力，還要提升自己的管理能力，全方位的提升自己。
1、在技術上，要有自己的特長，能適應行業發展
2、在管理上，要提升自己的定位，從管理的角度看待問題，解決問題
3、在職業規劃上，要有前瞻性，讓自己進退有餘
祝好運，望採納。

『貳』 作為一名程序員，從事技術管理工作，應該注意什麼事情

從程序員到技術管理，這要用人力資源管理的專業知識來看，就是一個非常典型的從「個人貢獻者」向「團隊管理者」角色轉變的過程，這也是各公司人力資源部門會重點關注的一個群體，幫助這些新晉升為管理者的人員快速進行角色轉換。

我將結合我人力資源從業生涯見到過的諸多案例、以及個人從員工升到管理層時的一些心路歷程，來回答這個問題。

第三步，掌握激勵下屬及增強團隊凝聚力的技巧和方法

依賴下屬完成業績目標的管理者，最重要的就是解決兩個問題，一個問題是讓下屬會幹活、有能力幹活；另外一個問題就是讓下屬有意願幹活，擁有一個能夠好好乾活的環境。

輔導和培養員工能夠解決員工幹活能力的問題，而激勵下屬及增強團隊凝聚力則能夠解決員工幹活意願的問題。主要分享3個主要方法。

• 自己做一個肯負責有擔當的領導人，遇事自己要沖在第一線，帶領大家一起解決問題和難題，有了榮譽、好處和利益，則更多把真正有貢獻的下屬推在前面；
• 鼓勵團隊成員之間互助互利，切忌主動製造內部矛盾和小團體；
• 營造一個以追求成長、進步、上進為榮，敷衍、懶散、得過且過為恥的團隊文化和氛圍。

『叄』 應該怎麼管理程序員

我是一個非常能忍耐的人，非常能忍。事情是這樣的，去年春天，由於上一個東家戰略失誤，導致我們部門被裁（悲劇啊），只好另尋他路，恰逢舊日總監空降到現在這家公司做老總，於是我就名正言順的過來做嫡系部隊。可等俺入職後，才發現這家公司水很深啊……。溜須拍馬的人比比皆是，竭盡所能討好領導，有些話我聽著都覺得臉紅心跳，胃部翻騰。此為公司第一陣營：諂媚，技術不精，管理不強，但是嘴上功夫了得，總能討得公司一把手二把手歡心，無所不用其極，堪比現代「和珅」。這一層人比較少，金字塔尖嘛。公司第二陣營：埋頭苦幹，一心只讀「聖賢書」，兩耳不聞「窗外事」。這是一群被極度剝削的新人，新時代的農奴，工資在公司墊底，升職沒他們，加薪更別想，技術沒人帶，基本處於群龍無首狀態，每天得過且過。這一層人最多，是整個公司的金字塔底，任憑黃沙蓋臉，毫無怨言。公司第三陣營：技術「大牛」，是的，這群人一般都是個小頭頭了，管理著為數不少的第二陣營，愛好鑽研技術，溝通能力基本為0，未接受過正規化訓練，一件事情要反復說多次方能「略懂略懂」，平時對自己手下不管不問，老子研究高深演算法，你們還是自己看書學習吧。好吧，我來了之後就有了第四陣營：不服管教派。 先說說幾件小事：1.剛來的時候，安排我進了一個開發中的項目組，讓我寫一個圖片處理和加水印的模塊，圖片處理，其實就是根據用戶上傳的圖片(像素很大，不適合網頁展示)，壓縮成各種尺寸並加上網站logo水印，兩天後，我寫了一個通用的介面，傳入圖片的原始地址，水印地址並輸入要生成的尺寸就可以了，給了他們一個打好的jar包。入口參數都用「中文」注釋好了，可後面一直到一個月後，還是老是被問介面怎麼用。2.其二，因為存儲的圖片很多，很大，項目組決定用分布式存儲，選了Hadoop，這任務又被委派給我了，我一看，哥也沒搞過啊，but，難不倒哥。上官網查文檔，上google查資料，經過幾天的折騰，終於把分布式集群搞好了，那個時候公司就一個運維，只會裝系統搭路由，Linux系統安裝和配置都是俺自己搞的，系統搞好後死活上不了網，又把機器從頭到尾檢查了一遍，去問運維，說我DNS地址設錯了，試了好幾個包括他給我的都不行，我不死心，去問運維，聊天的過程中無意間知道公司上公網是用路由過濾MAC地址的，果斷讓他查路由規則，我三台伺服器的MAC地址沒有一台在允許列表當中，oh，my god。好了，下面繼續講Hadoop，搭建好環境，寫完程序介面後就把圖片遷移到集群上，跑的還算穩定，就是讀取文件的時候有點延遲。後來哥有事請假兩天，打算回來解決延遲問題，可當我打開電腦興沖沖的連接Hadoop時，timeout了,What the hell did they do?去問經理，說是我離開後伺服器出問題了，項目組又沒有人會，就把圖片遷移回Apache，Hadoop集群關閉了。這尼瑪！不是坑爹嘛！！！！公司「元老」們對我的到來表示非常的不歡迎，項目組兩個月後就把我T出來了，讓我自立門戶，領導還專門關照我組建一個項目團隊時刻准備為公司沖鋒陷陣，這尼瑪，整個團隊就我一個光桿司令。以上只是技術的，一個對互聯網一竅不通，對編程壓根不懂的副總搞了一套CMMI作為管理手段，大會小會一個周要開三天，還有N多管理上的事情，不一而足，以至於我來兩個月後就想離職走人。後來想想，就這么走了太特么懦夫了，我要組建自己的團隊。於是乎招兵買馬，從招聘、帶人，制定項目規范、代碼規范，學會了js，struts(以前做軟體，沒摸過這些，慚愧……)，從去年年中的1個人道現在的6個人，我的項目組成型了。 好了，不扯閑話了，轉入正題。我有182的身高，80kg的體重，我會一些拳擊，練了五年田徑，可是我從來不跟人拳腳相向。在生活里一直信奉「人不犯我，我不犯人，人若犯我，先讓兩個回合」的至理名言，可是今天早上上班打開郵件，我就不淡定了。 公司新推出了績效考核，特別強調要量化量化再量化，最極品的是要量化「每周」寫的代碼行數。其實呢，大家都懂的，工作上按時把工作計劃里的工作完成，保證正常上線，其實就OK了。可這位副總，不懂不說，還特別不信任員工，不捨得權力下放。不知道去進行內部團隊的構建工作，偏愛相信外面什麼培訓老師，今天早上，竟然在郵件里，赫然把外面老師考核項寫在績效模板里，還佔了20%的比重。一個根本不在公司，沒和項目組成員進行溝通交流，連我們做什麼項目都不知道的所謂「老師」，竟然要給我們績效考核的「工作能力」和計劃能力打分，真是奇葩啊！！此郵件一出，「和珅」們拍手叫好，高呼領導英明，堅定的站在公司領導這邊堅決執行新規定；「農奴」和「大牛」們依然擺出關我屁事的姿態，只是農奴看書的時候把頭埋的更低了，大牛們在寫代碼的間隙，會抬頭眺望窗外，若有所思。作為不服管教的一撮人，自然是強烈的反對，再聯想來了一年了，公司對加薪一事只有書面提過，CMMI文檔還躺在SVN里。我覺得快要達到爆發的臨界值。其實，我們程序猿都是很善良的，真的為了公司的項目可以整日加班，挑燈夜戰，只是，時間長了，付出和回報不成正比，心也就冷了。俺帶人時間不長，不過也總結了一些方法和道理，雕蟲小技，眾位莫笑。1.團隊要規范： 從項目使用工具到代碼規范，最好統一，有利於項目集成和維護。一個項目立項到結項，編碼、測試、日誌、監控、文檔……，每個環節都很重要，關系著項目質量和進度，從這些環節抓規范，建立起一套良性體系，不論是對於成員還是項目本身，都是好處多多的。在項目組不忙的時候，適時的安排一些項目組會用到的技術進行鑽研，寫成文檔並做簡短的培訓分享，對技術總結，口頭表達和書面總結能力的提升都是有益處的。2.成員管理： 對於新手，要用正確的方法積極引導，鼓勵他們多動手，不要埋頭看書，畢竟看書和實際寫代碼差別還是很大的，每次帶新人我都戰戰兢兢，一開始的習慣很可能影響到他們今後職業生涯，每每想到這點，肩上壓力倍增。對於老手，要善於發揮他們的長處，以此帶動項目組其他成員，共同進步。平時要多關心了解組員，讓他們覺得項目組就像家一樣，大家都是兄弟，在攻堅克難的時候，這種團結有愛的環境對於解決問題有奇效。在公司損害到成員利益的時候要堅決和成員站在統一戰線。3.工作流程： 編程是一件需要專注去做的事情，所以在日常工作中，在不影響項目進度的情況下，流程越簡單越好，繁雜不合理的流程會讓項目進度嚴重拖延，且打擊團隊士氣。4.對於公司： 真的希望有些對這個行業不懂的老總能看到，不要再用你的一家之見來做出錯誤的管理決定，殘害手下的員工了。這個行業和傳統行業不同，不是請幾個講師就可以把公司管理好的，那是狗屁。每年請講師花幾萬，從裡面拿出一部分獎勵給工作出色的員工，效果要好的多。而且我們這個群體非常善良，你不提加薪，我們很多時候都不好意思提，真的。可是程序員也是人，人心易冷，那些新人累死累活工作一年多，還拿著兩千露頭的工資，每天還在喊著讓他們加班趕進度，可能嗎，對了，現在加班費都沒，晚上加班連晚飯都不提供一頓，我只能呵呵？即使你把人留在辦公室，心早已不在了。今天牢騷到這里吧，只要我在公司一天，就不能讓這些不合理的東西影響到我的組員，我會戰斗到底。最後，最近研究學習Swing，得到園子里不少大牛（不加引號的哦）的幫助，俺心裡十分感激，等俺學成歸來，一定出個專輯，好好報答各位園友。 多謝各位建議，小弟俺現在待遇還不錯（算是嫡系優待吧），只是看不慣那些「和珅」黨，並試圖找出自己的管理之道作為對公司亂搬亂套管理模式的回擊，畢竟手下還有六七個人，我走了就真的沒人帶這些兄弟了，他們也不會自己爭取利益，真的是很善良的小兄弟，所以在我吃飽喝足的情況下，不能讓兄弟們挨餓受氣。

『肆』 程序員如何方便的管理自己以前寫的代碼

一、代碼的最大長度。
雖然在Java的編譯器中對於代碼的最大長度沒有硬性的規定。但是如果代碼的長度太長，超過了編譯器的最當行寬，顯然閱讀起來比較麻煩。為此根據筆者的經驗，通常情況下Java源代碼的行長度不應該大於80個字元。如果超過這個長度的話，在一些開發工具和編輯器上就無法很好的顯示。如需要通過滾動條來顯示後面部分的代碼。當其他項目成員閱讀這超長的代碼時，就會看得眼花繚亂。當人的溫飽問題解決了之後，就需要開始注意美觀方面的問題。所以程序開發人員在開發應用程序的時候，要盡量避免書寫長的代碼。如果代碼的每行長度確實需要超過80個字元的話(最好將每行代碼的長度控制在70個字元左右)，那麼就需要對代碼進行分行。
二、在恰當的地方對代碼進行分行。
筆者建議將Java源代碼每行的長度控制在70個字元、最大不超過80個字元。當超過這個字元長度的時候，開發人員就需要考慮在恰當的地方對他們進行分行處理。不過這個分行也不是說開發人員想在哪裡進行分行就在哪裡進行分行。這個分行是有一定技巧的。雖然這些技巧大部分並不是強制性的規定，但是都是一些專家們的經驗總結，可以提高代碼的閱讀性。為此筆者希望各位程序開發能夠嚴格的遵守。
技巧一：高層折行優於低層折行。
這個技巧是說，在考慮對代碼進行折行處理的時候，需要注意代碼的層次性。如某段代碼涉及到混合四則運算，而四則運算又有明顯的運算順序，此時對代碼進行折行時就最好能夠在四則運算的關鍵順序上進行折行處理。如現在有如下的一段代碼：
Mynum=mynum1*(mynum1+mynue2+mynum3-mynum4)+8*mynum5
如果要對這段代碼進行折行的話，該在哪個地方加入一個折行符號呢?如果是筆者處理的話，筆者會按如下的格式對代碼進行折行處理。
Mynum=mynum1*(mynum1+mynue2+mynum3-mynum4)+8*mynum5
這主要是根據四則運算的運算層次來進行折行的。顯然，*符號的優先順序要比+符號要高。所以在+號前面對其進行折行處理，那麼就可以一目瞭然的反應出代碼的運算層次。可以大幅度的提高代碼的閱讀性。所以代碼折行的第一個技巧就是高層折行優於低層折行。如此的話，可以使得應用程序的結構代碼更加的清晰，更容易被團隊成員所理解。
技巧二：在運算符前面進行折行處理。
其實在如上的折行技巧中，還隱藏著一個規則，即在運算符之前進行折行。如上例所示，筆者就是在+號前面進行折行，而不是在+號後面進行折行處理。這主要也是考慮到代碼的可讀性。如上面這個例子中，如果在+號後面進行折行處理的話，則下一行就會給人一種憑空多出來的感覺，顯得代碼很不連貫。跟這個規則類似，如果在折行處理的時候遇到逗號時，那麼最好能夠在逗號後面進行折行。如在一個方法中，需要傳入5個參數。此時如果代碼行比較長，那麼就需要在幾個參數之間進行折行處理。此時最理想的折行位置，就是在某個參數的逗號後面。注意，使在逗號後面進行折行，而不是在逗號前面。因為一個參數一個逗號是匹對的。而如果一個逗號加一個參數，則讓人看起來很不舒服。
技巧三：這行代碼的對起方式。
當不得已對代碼進行折行處理時，下一行的代碼應該與其同等級的代碼行左對齊。如上例所示，在+號前面將某一段四則運算公式進行折行處理的時候，其+號符號已經採取縮進處理。其縮進後的效果就是要與其同等級的代碼行左對齊。如此的話，明眼人一看就知道這段代碼採取過折行處理;而且跟上一行代碼的層次關系。當一段代碼被分割成三行甚至跟更多行數的時候，這個規則會非常的有用。如果能夠嚴格遵守這個規則，即使將代碼分割成多行，看起來也不會覺得那麼混亂。反而給人一種比較有層次的感覺。
另外在採取縮進處理的時候，可以利用Tab鍵來提高縮進處理的效率。因為直接按空格的話，有可能空格字元數量不一致，會讓人覺得層次不起，產生比較大的混亂。一般情況下，當代碼行兩側距離頁邊的距離比較大，看其來不怎麼舒服時，可以在代碼行中通過插入TAB鍵(會在代碼行中連續插入8個字元)來提高代碼的閱讀性，讓代碼的縮進實現統一。
技巧四：為變數尋找一個合適的位置。
在編寫應用程序時，盡量將變數聲明放置在一個代碼塊的開始處，也就是說{}花括弧的開始位置。雖然說可以在需要使用變數的時候再對其進行聲明。但是筆者不同義如此操作。因為如果在的呢感到使用變數的時候再來聲明變數時，會降低代碼的可讀性。同理，也需要避免低層聲明與高層聲明重復，這樣會引起代碼混亂並可能引發程序功能性錯誤。而且這種錯誤在後續的排錯中很難被發現。為此要在應用程序開發的時候就要盡量避免這種錯誤。
在聲明變數的時候，有時候可能代碼很簡單，生命變數的行總共加起來也不會超過十個字元。此時能否把多個變數的聲明寫在同一行呢?從就技術上來說，這是可行的。也就是說，Java編譯器允許將多個變數定義在同一行上。但是從閱讀性上來說，這並不是很好的做法。筆者的建議是，即使變數定義再簡單，或者變數比較多，也最好分行進行變數的聲明。也就是說，一行聲明一個變數。這可以提高代碼的可閱讀性。而且有時候往往需要對變數加一個注釋說明變數的用途，如果以行定義一個變數，添加行注釋也相對簡單許多。
總之，以上的這些折行的規則基本上不會影響到代碼的運行。但是，對於代碼的維護與後續的排錯、升級、二次開發等等具有不可忽視的作用。而且現在基本上應用程序開發式團隊開發，故大家都遵守同樣的代碼編寫規范是非常重要的。筆者在開發一個應用程序的時候，事先都會花一定的時間，跟項目成員強調這些折行的規則。目的只有一個，就是提高代碼的可讀性，便於後續代碼的共享與維護。畢竟後續面對這些代碼的，並不是客戶，而是我們自己。我們程序員在編寫代碼的時候，不能夠搬起石頭砸自己的腳。筆者認為，現在一個合格的程序人員，不僅技術功底上要過得硬，而且還必須要遵守這些無形規則的約束。難怪現在這么多企業在挑選程序開發人員的時候，都會註明良好的編碼規范。現在對於這些無形中的條條框框，項目經理已經開始重視起來。

『伍』 程序員的職責

1、技術路線，這條路線到達架構設計師的人，並不多，能夠到達的都是程序員中業務非常精良且具備大局觀的人物。我的理解，架構的職責是產品需求提出後，能夠通盤考慮開發的穩定性、擴展性、各項性能指標的良性發展，架構通常要能夠預見到產品發展的未來方向，並從產品建立的初期，協助產品解決未來產品中可能存在的隱患問題的角色。
2、管理路線，這條路線其實是在技術路線基礎上的延展，但是更多考慮的不是技術或架構層面的問題，而是如何使用人員解決實際問題了。
3、產品路線，其實，很多人在技術往管理的路線上無法繼續，或者突然發現除了開發，自己也能准確把握用戶需求的時候的選擇。這種開發人員的特點往往是思路非常清晰，同時敏感、主動，有發現產品設計缺陷和漏洞的能力。

『陸』 如何管理你的程序員

簡言之，這些東西都是用來最有效的發掘你的員工的全部潛能的。你有了一個領導 基於此，我們通常會有一個重要人物，他可能是一個領導，一個經理或一個總監，等等。這就有了問題：這些人有什麼樣的特徵？一個管理者和一個程序員之間的不同之處在什麼地方？他們的角色可以互換嗎？ 為了弄明白這個問題，我們需要從人的視角上去思考。換種方式來說，我需要用到人的因素這個詞。如果他錯了呢？ 首先，要想管理人，你需要去理解他們。要做到這些，我們需要有情商。這並不僅僅指只針對我們這部分人。我們做的任何事情中都存在情感，你要從個人角度去體驗它，要熟練掌握，在我們的公司管理中的合作方式上不能忘記這一點。管理並不僅僅指控制和命令，它還包括聆聽，理解，溝通和對復雜的情緒上的問題給出有效的方案，這都是至關重要的。弄清他們的感受 很多人都忽略了管理工作中的這方面問題。有時候會很戲劇化，類似於這樣：「鮑勃，從明天開始你就是一名項目經理了，因為我們的程序員太多了，需要去管理，但不用擔心，你就要去上一個Scrum大師班了」。我們都知道這樣的認證證書是什麼樣的，有什麼價值。這跟那個10天的ICC培訓課程後成為一名教練的故事非常的相似——這行不通，你要銘記！ 另一方面，Mark Foster在他的標題為《How to make your dreams come true(如何實現你的夢想)》一書中談到，實現目標有兩種方式：推(Push mode)和拉(Pull mode)。前者是使用一種工藝上的技術來完成一項任務，比如程序員編程，而後者依賴於經驗、直覺和情商，從而選擇最好的方式解決一個問題——這是管理者的視角。當使用這種管理模式時，管理者是不能和程序員進行角色互換的，反之亦然。一些大公司通常使用這種管理模式。而這種方式有時會損失一些員工的潛能，因為在多個級別的管理職位中產生的太復雜的層級關系。相互協作 為什麼？很多的小公司都使用敏捷方法論。這是一種基於合作的方法論。上面描述的模式並不能滿足他們的需求。在不同層級上的管理者和程序員之間始終存在著一個隔膜。人們會被分成「腦力勞動者」和「體力勞動者」。結果就是導致我們失去那些同樣有大腦卻從來未被使用的人。如今，所謂使用有效率的員工就意味著把所有人都當作腦力勞動者。 Evan Rose 說：命令/控制(Command-and-control)文化使人們把公司成員分成了腦力勞動者和非腦力勞動者。他們讓腦力勞動者去思考，讓其他人去執行命令。這種文化中，合作沒有基礎。更重要的，信息的流轉應該是多向性的，而不是瀑布式的從高層經過多個管理層流到一線員工。事實上，如今的每個人都有資格成為一個腦力勞動者 現在出現了一種稱作自我管理的形式，這種形式本是我們這個世界的基礎。如果我們本來是自我管理的，為什麼不更進一步呢？也許我們根本不需要管理者。37Signals 和 DHH都實現了這樣的思想，描述起來如下：我們同樣也讓我們的團隊管理自己。每周，一個員工會站出來當管理者，他制定簡單的日程計劃，審查其他人的工作，更新公司動態信息，他對於其他同事來說是一個關鍵人物。這種職務輪換每周一次。你知道我們發現了什麼嗎？當每個人都知道自己要當一周的國王時，神奇的事情發生了。對管理者強迫自己做某些事情的抱怨消失了，因為職務的輪換讓他們有機會同時清楚的了解了圍欄兩邊的景觀。如果你讓員工們這樣做，這給了他們提高和成長的機會。找到共識，一起努力 但不要想當然。這並不是適用於任何地方任何人。但就像David說的：這種方法可行性很大。如果你能理解這點，你可以在團隊或部門里試驗一下。通常在小公司里當某方面出現問題時你能相當很快的對其作出反應，這能讓你更容易的避免重大事故的發生。 簡言之，不管你的管理方式是什麼樣的，永遠要記住，在公司組織結構的深處有一種叫「人的因素」的東西，它在等待著你去照顧，它能摧毀你所有美麗的計劃。唯一你防止這種災難發生的辦法就是要認識到：你在跟人打交道，不是機器。

『柒』 畢業之後從事程序員，該怎樣規劃自己的職業方向呢

第一，應屆畢業生需要快速積累經驗。

履歷和學歷都非常重要，如果哪個欠缺，就趁年輕趕緊彌補。一線互聯網公司對於學歷和履歷尤其看重。你前期不要過分看重薪資，如果一個大廠和一個小公司同時向你拋出橄欖枝，即使小公司給的再多，也要優先考慮大公司。假如你不是985高校或者碩士，你就要從技術層面快速提高自己。如果你在小公司里工作，爭取三年內進入一線互聯網公司。如果想要在這一行業長久發展，要有市場行情分析的能力，去學習最火的大數據，機器學習演算法等領域，必要時可以果斷轉行。

第五，最重要的一點：多存錢，為了以後做自己的產品

你是否甘願一直打工，一直看他們眼色？不，程序員高傲的內心不允許他這樣做。所以，老老實實多存點錢，為了以後自己創業做資金儲備才是王道。

『捌』 程序員怎樣才能走上管理崗位

想接受挑戰首先要認識自己，看自己是否適合做管理不防考慮以下幾點：對待問題是否公平公正，是否能夠犧牲自我的利益顧全大局，是否有洞察力，是否能夠了解組員的想法，是否能夠做出正確的決策在沒有條件許可的前提下……另外在該職責裡面有兩個重要的事情要做，一件事情是幫著老闆幹活，另一件事是替組員說話幫助他們爭取相應的權益，所以夾心層的處理方式是處理好承擔與託付，即責任的承擔和信任的建立。

技術管理者的技術不是最資深的，但應該具備專業的能力，並且是某個領域的技術和業務專家，因為一個人的能力是有限的，管理上有所建樹便註定了技術道路上深度有限，但他有自己的技術見解並能夠在需求把控、產品設計、架構設計中給予建設性意見並作出正確的決策，也只有這樣才不會變成空中樓閣的大領導，擁有良好的技術基礎是贏得你的團隊信任的前提，也是自己能夠建設一個可信任的團隊的前提。作為管理者只有得到大家的認可，大家的信任，才能進而營造一個可信任的團隊，使得各個部門之間互信，協調一致。而得到大家的信任作為管理者必須要有一定技術基礎，也只有基於該基礎才能做出正確的判斷力，才能夠確保團隊整體方向的正確性。

建議每個技術人員能夠經歷項目經理的角色，嘗試一下管理團隊，看一下有哪些問題要解決，換一種角度思考你所參與的項目，培養自己的大局觀，大局觀重要性在於能夠讓個體將一個事物分析的更清晰，只有站得高才能看得遠，大局觀對個人而言很重要，擁有大局觀會使個體在把握處理事情上更公正清晰，並更有利於作出正確的決策使得工作向良性方向發展。對於技術學習本身也需要融會貫通、舉一反三，這也是一種意義上的大局觀，所以思考角度決定著自己在其發展方向前進的遠近，不要只是將自己局限於技術細節當中。

認識自己很重要，因為只有自己做了擅長的事情才能夠事半功倍，游刃有餘，改變一個人太難，與其效果甚微的改掉缺點不如發揮自己的優勢。國外有一種創新的思維，認為缺點和優勢其實是相輔相成的，你的缺點正好反映出了你擁有它對應的優點，換一個角度揚長避短，真的就事半功倍了。想一想對於組員又何嘗不是呢，與其說服改變一個人不如知人善用，揚長避短。

『玖』 如何才能修煉成一名不可替代的程序員，避免裁員危機

程序員，就是從事程序開發、程序設計、程序維護的專業人士。

作為一種專業性極強的技術性專業，程序員的工作難度非常高，只有專業技能水平高超的人才能在這個領域獲得良好的發展前景。……那些實力不足的人，只能被最終淘汰。

因此，要想在程序員這一行里成為不可替代的人，避免自己被淘汰出局的情況，就必須具備以下幾方面能力：

1，高人一籌的專業技能。

在職場上，要想確保自身生存，就必須具備一項專業技能。……要想確保自己不被淘汰，就必須具備高人一籌的專業技能水平。

因此，要想讓自己成為不可替代的程序員，要想讓自己避免被淘汰的情況，就必須確保自己的專業技能水平高人一籌。

2，強大的羅輯思維能力。

程序，是一個邏輯性極強的系統。

一個程序的各個部分之間、各項功能之間，都存在著極強的關聯，也擁有著非常強的邏輯關系。

因此，要想編寫出性能優異的程序，就必須擁有極強的邏輯思維能力。……這是確保自己擁有更強實力、確保自己不被淘汰的重要能力。

3，高超的數學水平。

程序的表象，是一段代碼。而其核心，則是數學模型，是具體的演算法。……只有具備高超的數學水平，才有能力編寫出演算法精妙、邏輯嚴謹的程序來。……這是自己具備更高水準的關鍵因素。也是自己高人一籌，不可替代的關鍵因素。

4，精通至少一門編程語言。

編程語言是程序員在編程時所用的工具。……只有熟練掌握手中的工具，才能讓自己編寫出優秀的軟體。……編程語言有很多種，一個程序員不可能面面俱到。……但是一個合格的程序員必須掌握至少一門編程語言，這就是自己工作時最得力的工具。……運用這個工具，自己就可以編寫出優秀的軟體，就可以獲得更好的業績，最終成為不可替代的優秀人才了。……自己也就不可能被淘汰了……

『拾』 程序員四十歲以後該怎麼辦

這個問題，適合我回答。我是99年畢業的計算機系本科生，所以同學基本上都是40歲上下做it的人士。我就撿著幾個年輕時做過程序員的同學例子給你們說說，看看這些程序員40歲以後幹啥去了。

同學A，2000年去了某大公司H做開發，因為善溝通有親和力，後來逐漸脫離技術崗，做項目經理，售前，現在負責對外投資。

同學B，2000年去了某大公司H做開發，因為天賦好，技術崗位一路上升，做到中層領導職位，後來看好某新技術，毅然離職創業任ceo，堅持寫代碼至今。如今一邊經營公司，一邊寫代碼，一邊組織小樂隊吹拉彈唱，等著風口到來好起飛。

同學C，進入對日外包行業做程序員，現在自己組建軟體開發公司做老闆，時不常的還會弄弄代碼啥的。

同學D，進入對日外包行業做程序員被外派日本，後來定居日本，目前仍然是做維護代碼工作。

同學E，進入通訊領域做程序員，在換過多家公司之後，依然以資深專家身份玩弄著代碼，並以此為樂。

同學F，經歷了北漂創業，身體健康亮紅燈後，再次回到軟體外包行業打工。如今作為資深程序員堅持在代碼第一線，還經常加班。

同學G，畢業之後不久就炒了公司，做了軟體開發個體戶。從共享軟體到如今的APP開發，總能弄出名堂在排行榜中佔有一席之地。十幾年如一日，一邊瀟灑生活，一邊弄弄代碼保持排行名次。現在生活無憂，不停生孩子玩兒。

同學H，畢業後進了某大公司Z，做程序員。如今在Z司的下屬公司做某項目負責人。

所以說，各個行業呢，都是有深度的，不僅僅是寫代碼那麼簡單。只要你願意做下去，多年的行業經驗積累會幫到你。

軟體開發，或者說程序員工作，說到底就是一種工作。跟其他工作一樣，都是用來養家糊口的。喜歡呢，就做得開心些；不喜歡呢，早點轉行也好，或者繼續靠這個賺錢同時，培養點其他愛好也好，都行。