Manny李文輝
寫代碼是程序員的主要工作，但是卻不是最難的工作，最難的是踢皮球和吵架。
踢皮球
說起踢球你是不是腦海中想象著在辦公室鋪一個綠地毯，兩邊再架上一個門兒，組織十幾個程序員開踢？你想多了，程序員天天加班哪有時間踢球。我說的踢皮球是程序員之間、程序員與測試人員之間互相推諉的意思。
踢皮球是程序員工作中很常見的一個現象，而且某些人學的爐火純青，走火入魔。自己寫的代碼出問題了？不可能，在我的電腦上是好的啊？什麼，發現一個bug？不能夠，肯定是你的環境有問題！運行不了？更不可能了，肯定是你的編譯器版本不對，或者是你沒安裝什麼插件。
吵架
程序員之間一般不會有什麼矛盾，大家都是寫代碼的都是加班的難兄難友，不要太團結哦。
不過程序員測試之間就不好說了。測試拋來一個問題，程序員心底本能的反應就是:“哇哇，到底有沒有看我寫的運行教條件”。測試也不是省油的燈:“我就是按照你給的條件測試的啊，你想抵賴？就是你寫的bug”，這麼一來二去雙方吵起來了。
這個時候產品經理來了:“那個誰誰誰，這有個新的需求，你下班前給做了吧，客戶急著要！”程序員一聽本來就氣在頭上，再經產品經理這麼一折騰，程序員內心的小憤怒徹底爆發，一言不合就幹起來了。這真是一個鬱悶的故事。
程序員其實就想好好寫代碼，為啥就不讓人好好寫代碼，程序員要哭了！
C語言編程答疑
看到這個問題，從08年參加工作以來，已經做了10年的程序員了。從初期的java開發，到後來的php、python等語言的開發，經歷過不同的語言的學習過程。從早期的工程師，到後期的高級工程師、資深工程師、架構師，還擔任過項目經理的角色。從我的經歷來說，對程序員來說最難的往往不是寫代碼。
首先，程序員學習一門新的語言或者新的算法，只要理解了語言的規則和算法的本質，只需要使用某種編程語言實現算法的實現即可，這也是大部分程序員都擅長的。程序員是一個很特殊的人群，讓一個程序員去研究一門新的技術，往往能超過你的意料，對於他們痴迷的技術，甚至能夠廢寢忘食，我就遇到過我的同事為了解決問題，竟然到晚上才想起來自己沒吃午飯。
其次，程序員擅長跟計算機打交道，不知道是不是跟計算機打交道時間長了，大部分程序員跟別人溝通都不會很流暢。你會發現，程序員跟程序員之間，有說不完的話，而程序員跟陌生人，往往沒什麼溝通的語言。程序員是一個不擅長溝通的人群，這也能明白程序員為什麼經常會跟產品經理幹起來。還記得平安的產品經理提出“實現手機主題根據手機殼顏色進行調整”的需求，最後跟程序員幹架的例子吧。從程序員的角度來說，這明顯是產品經理在刁難程序員，而產品經理的思維是：不關心能否實現，只關心大眾的需求。
最後，我認為程序員最難的不是寫代碼，對程序員比較難得是：做項目的程序員比較難的是理解客戶的需求；對產品的程序員來說，比較難的是理解產品經理的需求。歸根結底，對程序員最難的還是“溝通問題”。
開心的溺水的魚
對於不同階段的程序員有不同階段的任務，所面臨的難點也並不相同，但是對於程序員來說，代碼本身的難度只在學習的初期有所體現，隨著編程經驗的增加，代碼本身的難度會逐漸下降，因為編程語言本身就是工具，只要多使用必然會越來越熟練。
通常情況下，編寫代碼的難度體現在以下幾個方面：
第一：算法設計和實現。編程的核心問題是算法問題，編程問題說到底就是個數學問題，這就是為什麼很多人認為編程難的原因，難在算法上而不是在編程語言本身上。算法實現還涉及到數據結構的應用，所以編程也被認為是算法設計加數據結構。算法設計和數據結構涉及到程序的執行效率，這對於大型系統來說尤為重要。對於研發級程序員來說，通常需要具備紮實的數學基礎。
第二：架構的選擇。架構設計、模塊化、數據交換、資源規劃、分佈式處理、併發處理等問題是程序員面臨的又一個難點，相對於算法來說，這部分難點需要大量的經驗積累和對技術本身的深刻認知，所以往往架構師都需要有豐富的實踐經驗。如果說算法解決的是核心問題，那麼架構解決的就是整體協調性問題。如果把算法設計看成是優秀的球員，那麼架構設計就相當於教練員，只有有效的配合才能取得好的成績。
第三：技術驗證和調試。研發人員重要的任務是驗證，驗證技術是一個漫長且複雜的過程，要模擬出實際的應用場景，然後通過不同的方案設計來驗證執行效率，這通常也是一個比較難的工作。技術驗證和調試需要一個團隊的配合，一個技術的驗證過程往往有眾多經驗豐富的技術專家來進行，所以這是技術含量比較高的工作之一。
程序設計工作是一個門檻相對較高的職業，通常情況下，程序員在整個職業生涯的過程中也需要不斷的學習。
作者簡介：中國科學院大學計算機專業研究生導師，從事IT行業多年，研究方向包括動態軟件體系結構、大數據、人工智能相關領域，有多年的一線研發經驗。歡迎關注作者，歡迎諮詢計算機相關問題。
IT人劉俊明
初級程序猿大部分都是寫增刪改查的業務代碼，增刪改查最需要技術含量的是查，歸根結底都是寫SQL語句，有的業務邏輯複雜一點就SQL語句複雜一點，或者數據庫裡不好處理就在Java代碼裡處理。只要數據庫學的還行，MySQL比較會用，Java功底有一定基礎，基本上都能勝任敲代碼的工作。
文|熱心哥哥宇文笑
業務複雜，有的系統尤其是一些toB的系統，比如一個上市公司的超市人力管理系統，這是非常複雜的，人事組織，薪資社保，還要針對不同地區分公司不同類別的員工進行不同的代碼處理。
需求變動頻繁，有些項目的顧問或者產品經理沒把控好，導致需求被客戶拖著走，搞產品的可能覺得也就變化一點點東西，實際上有的功能代碼需要後端重寫，數據庫的表結構一變，那改動也是得跟著變。咱們敲代碼的朋友最不喜歡的就是返工，我們寧願去接受更多的開發新任務也不想再去重寫自己以前寫的代碼。（不用說什麼重構，這些業務代碼重構其實並沒有什麼技術上的突破）
代碼優化，其實比較難得住人得，尤其是難住我們這些剛入行的程序員。有的業務數據量龐大，就得先考慮數據庫優化，代碼多線程優化，總之優化代碼倒是一件比較進階的拆事，比敲代碼難。
來說說，作為程序員的你，最難的什麼呢？
極客宇文氏
工作十餘年，見過很多代碼，也寫過很多代碼，當面對這些情況的時候，我也會束手無策：
不確定的需求
你見過這樣的業務人員/客戶麼？對方說：
“我給你提個需求，但是這個需求我還沒有想好。”
“ 你們可以先開始開發，等我想好了再隨時調整。”
“ 你們先畫頁面吧，頁面上有哪些東西我不太確定，等你們做完一版後，一起看看吧。”
- 想法可能隨時在變，好不容易溝通確認下來，剛動手寫了幾行代碼，就接到一通電話：“這個需求，我跟我們領導彙報了，我們領導又有點兒新的想法。”
重構別人的代碼
很多時候，程序員都是在做二次開發，可能進入新公司的時候，項目已經運行好多年了，接手的代碼一沒文檔，二沒註釋，並且沒有任何工作交接。
這種時候，每當有新的需求需要做，大部分時候程序員都會選擇重新寫一套邏輯。萬不得已必須要改老代碼的時候，一定會戰戰兢兢的。
程序員最煩兩件事：
第一件事是給自己的代碼寫文檔；
第二件呢？是別人的程序沒有留下文檔。
沒有思路的代碼
寫代碼之前，不管是畫流程圖，還是寫設計文檔，又或者隨手寫一些偽代碼，這些都是代碼的思路。如果面對一個需求，你欠缺業務知識和邏輯思維，那麼可能連一點兒思路都沒有，寫代碼更是沒影兒的事兒了。
所以我老說，寫代碼也是需要一些“悟性”的，也是需要業務知識積累的。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
絕大多數外行人可能會認為對於程序員來說，最難搞定的工作就是寫代碼，而實際上並非如此。要知道寫代碼可是程序員的基礎工作，也是程序員的看家本領，當然好的代碼還要具備高內聚，低耦合，高效率，易維護，易擴展等諸多標準，但是就寫代碼本身而言，對程序員來說並不是難事，因為還有很多事情遠比寫代碼要頭疼的多。不信？那我就一一跟大家吐槽一下：
尋找最佳解決方案
比如在工作中給你一系列的需求，你被要求設計和構造技術上的解決方案。這包括了設計數據結構，算法，邏輯上的封裝等等，還要考慮到用戶安全方面的因素。最大的挑戰在於既要確保你的設計可以滿足客戶需求，讓客戶認為合理，同時還要在項目時間允許範圍內完成。
編寫文檔
如果你覺得編寫文檔so easy，那麼我想你是對撰寫文檔有什麼誤解。撰寫文檔需要說明代碼的含義並解釋應用的工作原理。這就包括了獨立的文檔文件和代碼註釋，讓更多的人理解你的代碼。要知道這是一件非常耗時的工作，如果沒有人去讀它們的話就是純屬浪費時間了。畢竟相比於寫文檔，很多程序員還是更愛寫程序。
維護他人的代碼
這是絕對是一項送命任務。有時候因為離職或者工作調整等原因，你需要維護和調試其他程序員的程序，或一部分代碼。在這個過程中你需要用盡一切辦法理解前任開發者的意圖，特別是當這些代碼寫得很差，也沒有註釋和文檔可以幫助到你時，簡直可以用一場災難來形容。
解釋自己的工作
向周圍的非程序員朋友，家人，同學解釋自己的工作是在做什麼，不做什麼。你愛的那些人可能不理解你在做什麼，而且你還不斷的被問及計算機相關的一切問題。這種感覺比加班通宵還要絕望啊……
作為程序員，大家認為比寫代碼難搞定的事情還有哪些？歡迎在評論區暢所欲言，分享自己的經歷。
從不加班的程序猿
最難寫的不是代碼，代碼只是邏輯控制的描述，當然好的代碼更能提現好的邏輯。
那麼最難的是什麼呢？
1、是對軟件平臺底層原理的理解，這樣才能清楚很多代碼為什麼有各種優化以及高效的寫法，如果您使用的是C、C++、Delphi等直接與操作系統進行交互的語言平臺，那麼請了解操作系統原理、編譯原理、需要特性等，如果是.Net、JAVA平臺，請了解運行時環境及虛擬機原理，以及語言平臺特點，另外，不管什麼語言或平臺，瞭解更多的第三方庫最好
2、算法與結構，這是最難的，所有程序的實現都是算法與結構的實現，平時已經用到的很多，比如各種排序算法，集合類庫，為得到某種結果的邏輯計算，所以說，數學好的人，在軟件上走的更遠（如果只是應用層面，有些數學基礎就差不多），圖像識別、語音識別、機器學習、神經網絡等等，都是算法和結構的實現，所以，niubility的東西，都需要數學好。
TheWindOfFreedom
絕對不是！
沒工作之前，我是這樣覺得的，但是工作之後，我才發現，有更難受的！
工作中，最難的是什麼？
毫無疑問，是源源不斷、千奇百怪的需求！
如果在工作中，遇到好一點的產品經理，他和你商量著，讓你開發功能，什麼能做什麼不能做，都會討論的清清楚楚！
但是如果遇到比較軸或者沒有立場的產品，這才是真的難受！
比較軸，那麼你和他就聊不下去，明明一個功能不合理，可是他會和你槓到底！
沒立場，這一般都是新手產品，他們面對甲方的需求，只會同意，到頭來苦的就是開發人員！
最奇葩的是，沒有產品，臨時做一個東西，直接給開發發一份需求文檔，照著需求文檔做界面！
真的是把前端開發當成產品、美工、開發一體的了！
所以，我覺得最難的不是代碼，難的是工作中的奇葩事，你覺得呢？abigbread2018
有時候代碼還是其次的，真正難的是弄懂開發的相關領域的業務。
比如你做證券，你要懂金融相關的基礎知識。
你做倉儲，你要去了解物流的基本概念，流程等等
你做財務，財務的基本知識你也要懂。
不懂這些，你連如何跟客戶溝通，如何獲取需求的第一手資料都不知道，就更不會有後來的設計和代碼實現了。
HELLO開源
程序員最難的是找女朋友，
每天沒日沒夜的加班，
每天蓬頭垢面的，
每天一堆的bug焦頭爛額，
每天需求推倒重來，
每天和產品經理扯淡，
哪裡有時間交女朋友？
哪怕有，也都跟別人跑了！
對吧？
