在很多人眼裡，程序員是一類高薪、“高危” 的職業。 他們穿着格子衫、頂着一碗超帥的光頭，能修電腦、能黑網站、簡直無所不能。 。 。

但直到我自己當上程序員，才發現其實很多人都是對程序員的誤解。除了外行的誤解外，還有很多來自于程序員同行的誤解。

今天我就結合自己的學習 / 工作經曆和感悟，分享下我對這些誤解的看法，當然也希望給程序員朋友們一些實質性的建議和啟發。

作為達不到平均的一方，我覺得這句話傷害不大，侮辱性極強。

程序員平均薪資可能的确稍微高了一點點，但是年薪百萬真的是幸存者偏差了，真的極少數程序員（尤其是隻憑技術的程序員）能做到這個地步。如果你拿我和小馬哥去平均，那我還人均千萬、人均上億呢，對吧？

之前很多同學看我都吐槽說：“你為什麼還有頭發，你個菜雞！”

我覺得，如果發量代表水平的話，我應該比在座的大多數同學都要濃密才對。

所以有沒有種可能，是因為太菜，需求做不出來，Bug 改不完，所以才經常熬夜加班，精神壓力極大，導緻頭發熬沒了呢？

咳咳，别罵了别罵了，是我本人了。

我覺得這個要分情況。拿我自己來說，我一般在 2 種情況下敲鍵盤比較快：

要麼是在寫賊簡單的、不用動腦的重複代碼（比如增删改查）；

要麼就是在回消息聊天。

所以有沒有種可能，程序員的手速是通過摸魚、怼産品、重複勞動、或者是平時打遊戲打得多而提升的呢？

不過畢竟要經常敲代碼，所以程序員的手速通常都不慢。

我記得我之前不怎麼加班的時候，就有人經常問我：你為什麼不加班？

這個問題直接把我問懵了，好像我真的覺得自己應該加班，不加班是罪過。

我想說其實程序員也是有個人時間的。至于為什麼程序員經常會加班呢？我覺得主要是以下幾點：

首先是我們的程序代碼是越寫越多的，寫得越多，系統越複雜，Bug 就越多。就拿我自己來說，剛做項目一周的時候，就那幾行代碼，Bug 也好查。但現在項目做了一年多了，用戶也多了，很多陳年老 Bug 慢慢被發現了，而且經常牽一發而動全身。

第 2 點是程序員對排期的錯誤估算。我發現一個有趣的事情，需求是做不完的，你需求做得越快，新需求來得就越快；而且我們很多時候隻考慮了做需求的時間，沒有考慮改變 Bug 的時間。但現實卻有可能是改變 Bug 的時間比開發的時間還要長。所以可能的話，還是别把需求安排太滿，預留一部分時間改 Bug。

當然還有很多其他因素，比如不會拒絕需求、不會跟産品 Battle、缺乏經驗、寫的系統不利于維護、或者身邊的人都很卷你不好意思走等等。總之加班是由很多方面決定的。

對不起，我覺得這個并不是誤解。。。這是真的！

以前我遇到過一些莫名其妙的事情 Bug 就死扣到底，但後來我就學聰明了，先重啟一下編輯器、重啟下軟件，說不定就好了。因為 Bug 不一定是你造成的，可能真的是編輯器造成的 Bug。

大家就理解為電腦死機後，重啟一下就又能開機了。原理應該是差不多的（将程序置于初始化狀态）？

有很多程序員是這麼認為的，覺得工作中也用不到自己寫算法，用個現成的函數、類庫，或者上網抄一段就能搞定對吧？

但事實上，有些時候并不是你用不到算法，而是你缺了一些知識，根本想不到可以用算法去更好地解決問題。比如同樣是存儲和查找 20 萬 個單詞，沒學過算法，用數組也能存、也能順序查找，但是時間空間都存在浪費；如果你知道前綴樹或者其他數據結構，就可以大幅節省存儲空間、提升查找效率。

我覺得自己學的知識越多，反而會越覺得基礎才是最重要的。因為上層的技術不斷發展、不斷叠代和淘汰，但是底層原理、編程思想、基本功一般是不會變的。

當然也有同學問是不是前端就不用學數據結構和算法了呢？隻能這麼說，這一塊在前端面試的比重的确不大，時間緊大家可以優先以技術框架學習為主，但是有空了還是要好好補一下基礎。

我覺得這句話對一半，應該是追求 特定條件下 的最優解。

沒有工作經驗的同學會覺得程序就要完美，看見程序有 Bug 了、寫得不好看了、前人留屎山代碼了，多少都會嫌棄。

其實在真實工作下，我們沒辦法把程序寫到完美，往往是空間和時間的權衡，比如 HashMap ，用内存提高查找效率；或者人力成本和資源的權衡，比如花錢買現成的服務，節省開發時間；再或者是需求和實現的權衡，比如天天都讓你做緊急需求，你還有空去優化架構、有空去追求極緻的性能麼？對不對，代碼屎山就是這麼來的。

所以這裡就要求我們在寫代碼之前先做調研設計，多思考幾種方案，權衡利弊，然後從中選擇相對的最優解。同時也希望對别人寫的代碼多一些包容，把你放在别人的場景下，你未必能做得更好。

在學校的時候，我的确是這麼認為的，當時經常跟舍友吹牛逼說我今天又寫了多少行代碼。但現在仔細回想一下，絕大多數可能都是複制粘貼、增删改查。

進了公司後我才發現，真正寫代碼的時間很少，像前期的需求評審、跟産品 Battle、方案設計、技術選型、溝通、資源協調更重要，也往往更花時間。在你想清楚要不要寫代碼、怎麼寫代碼後，再去寫代碼，那時你會發現隻不過是一種翻譯工具而已。

而且就我觀察下來，一般職級越高、工資越高、能力越強的人，寫的代碼反而越少。并不是他們寫不出來，而是他們已經寫得太多了、已經有了很多經驗、更懂得去利用工具來脫離重複的工作，比如寫個自動化腳本、重複代碼生成工具之類的。

還有一方面原因是公司需要他們去做更重要的事情，從底層的執行慢慢轉變為上層的決策，比如剛剛說的方案設計、或者系統架構。大佬定了個框架，寫個 Demo，剩下的就交給我們小碼農對吧。

所以代碼量是無法真正權衡水平的，在做需求時多去思考更合理的解決方案、寫代碼時盡量避免重複勞動，才是我們要追求的。

我覺得這個誤解和上一個很像啊，如果你覺得程序員的工作就是寫代碼，寫得多、寫得快就是強者，那你就真的把自己當成碼農了。

我覺得衡量優秀程序員的标準絕不止有技術，比如問題的解決能力，同一件事，你完成得比别人快比别人好；比如業務理解能力，給你一個需求，很快就能判斷它是否合理、梳理清楚流程；比如溝通能力，你能夠很好地維護用戶、組員、同事、跨部門合作者的關系，從雜亂的消息中提取出有效信息；比如産品思維，你能給出更好的建議來推動産品發展；比如管理能力，善于組織成員、推動團隊發展；再比如分享表達能力，能把自己學會的東西清晰地講出來、讓别人也能理解，我覺得是一件很酷的事情。

- EOF -

為了幫助大家，輕松，高效學習C語言/C ,給大家分享我收集的資源，從最零基礎開始的,幫助大家在學習C語言的道路上披荊斬棘！

編程學習書籍分享：

編程學習視頻分享：

整理分享（多年學習的源碼、項目實戰視頻、項目筆記，基礎入門教程）

歡迎轉行和學習編程的夥伴，利用更多的資料學習成長比自己琢磨更快哦！大家也要把握住大學的時光，抓住成長的每一次機會哦~

對于C/C 感興趣可以關注小編在後台私信我：【編程交流】一起來學習哦！可以領取一些C/C 的項目學習視頻資料哦！已經設置好了關鍵詞自動回複，自動領取就好了！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!