1樓：
你們真的太過分了，我頂多就是
這個好麻煩。。。。
一上午（下午）弄完了。摸魚
老闆:弄得怎麼樣了。
出了乙個大概效果，我改一改明天能加進去。
繼續摸魚。
2樓：元遲
1.和組長說馬上寫完了第二天中午還差乙個介面
2.和產品說實現不了 （內心，太麻煩了，懶得做）
3.和老闆說這個需求實現需要100個工時 （實際一天）
3樓：undefined
1.不應該啊，在我機器上跑還好好的啊！
2.快取清一下就好了
3.本地先這樣寫，到線上我會改回來的
4.下班之前弄好，。。。。
5.瀏覽器不相容
4樓：偷程式碼的貓
1、我們後端跑for很消耗效能
2、這個我們後端處理壓力很大
3、產品大家都是/都不是這麼做的，你這個需求有問題4、他家這麼做很low，我們不能學
5、專案不能上線是因為我們單元測試還沒寫完6、本來單元測試覆蓋率超過70%，現在只有40%是因為產品提了新需求7、簽字畫押，父老鄉親各位同仁見證，誰變誰是狗
5樓：千魚記
就是對時間和問題解決的承諾
現在碼農尤其是剛出來3-5年的，對技術不專研，對問題不充分考慮完全是在工作中進行學習，必然出錯。
等於公司花錢給他學習實驗
我說的是一些普通的問題，還麼有扯一些比較複雜的演算法這種比如乙個前端，每乙個簡單的JQ都要琢磨幾個星期，還天天加班。有這時間JQ都可以從頭學一遍了。 針對中小企業，開發大部分絕對是有現成的能用就用，但是對現成的可用模組毫無了解，非要自己從頭寫。
這就是中小IT公司鼓吹COO重要性的所在，沒有乙個資深COO來把控，中間坑太多了
6樓：柏梓涵
這是（Windows/Linux/macOS/Android/iOS/Intel/AMD/NVIDIA/編譯器/直譯器/聯結器/Unreal/Cocos/Unity/業務層/系統層/資料層/底層/編碼/配置/）的鍋，反正不是我的鍋。
7樓：得閒野鶴
「這這麼可能會有Bug？ 你讓我來操作看看！」
拖過運營手裡的鍵鼠，一頓操作：「你看這不是沒有問題嗎？」
回去偷偷把剛剛運營點出來的Bug給改了。
8樓：「已登出」
經常加班，好忙啊。
（作為後台、系統架構必須得陪著team提供技術支援，自己手上的事情其實已經做完了，大多數時間都在打遊戲……）
9樓：
我覺得碼農的乙個很大的困擾就是，由於其工作內容非常專業和需要乙個人持續持久的專注度，導致工作內容的不透明性，不可見性，抽象性，不可測量的屬性。由於其他人只能通過可觀察的角度去衡量其工作內容和進展，所以就會在雙方之間造成很多困擾和誤解。另一方，可以認為是監工和監督方，管理者，客戶等，用甲來指代。
程式設計師用乙指代。
（1）甲認為乙的工作性質是，因為乙掌握了工作方法和技能，所以天然的就會做其工作。實際上，在很多情況下，乙在接到乙個實現需求時，通常不知道如何做到，它需要一定時間去摸索，研究，學習和熟練，才能進入正常工作節奏。
（2）甲認為乙可以準確的預估乙個專案的完成時間。錯誤，實際上很多情況下，由於未知因素太多，乙無法準確預估其完成時間。
（3）甲認為工作內容可以被剝離拆分和簡化，可以在此基礎上取捨來加快速度。這一條當然嚴格上來說不是錯的，但是由於甲不了解也不願技術實現細節，所以其想法很可能和實際不相容不可行，所以他們認為的東西經常不會被乙接受和認可。
（4）甲認為工作內容是線性增長的。這一條當然巨集觀上也是正確的，但是對於碼農來說，尤其在微觀上卻極不規律，微觀上根本就不可能做到線性。因為工作內容就不是線性關係。
換句話說，也許，2年的工作成果是一年的二倍。但兩天的工作成果經常不會是一天的二倍。在實現時，是乙個圍觀上經常重構的過程，就好像搭建乙個機械人，這個機械人不斷的區域性成型，又不斷的被區域性拆散，工作不像滾雪球，越滾越大，而是好像揉麵糰，每加入一點新的麵粉，程式設計師就不斷的揉踹麵糰，才能讓新的麵粉和現有的麵糰融為一體。
所以有乙個答案裡提到這一天，就是工作回報上的進度，看起來貌似在和時間成線性關係，例如，這個月 10%，下個月 20%，到了第 10 個月，你會發現程式設計師的進度，開始以越來越小的幅度增加，成為逼近 100% 的漸進線。這當然無法反應實際進展，然而，確實被甲方需要逼迫的產物。
10樓：AriexBear
我來分享乙個我見過的最牛的注釋：
// This is a horrible solution, only for fast deliver! I will change it ASAP!!!
我查了一下版本庫，這段注釋已經存在了12年了。
11樓：jusalun
根據工作年限和經驗而分
1-3年的：這個需求應該不難，大概7天左右吧。壓著期限完成了，年輕氣盛，苦逼兮兮的寧可加班也要在期限內搞定
4-5年的：這個我研究一下，待會跟你說工時。要了7天工時，實際上5天就搞定了。
6年以上的：我需要走POC流程驗證下資料準確性，是否滿足需求，然後才能告訴你開發工時。實際上有兩種結果，乙個是直接砍掉PM的需求，乙個是乙個月起價。當然工時不到一周的都會甩給小弟做
12樓：
產品: 把啦啦啦啦啦啦啦啦啦啦啦啦啦啦.....
我: 《眉頭緊鎖, 目不轉睛》
產品: 需求大概就是這樣, 你估算一下大概要多久?
我: 恩......《深思中》 => (發呆中)產品: 怎麼樣?
我: 需求有點難度, 至少大概要乙個星期....《慎重的表情》
產品: 行, 那就乙個先乙個星期, 如果時間不夠到時候再說-----分割線--------一星期後的最後一天的中午......
產品: 上次和你說的需求怎麼樣
我: 哦.. 你說那個啊《臥槽, 什麼需求? 小本子呢?> , 我看看哈,恩, 快完成了, 過程比較順利
產品: 下午能出來吧, 沒問題吧
我: 沒問題
-----分割線----2-3 小時後
我: 好了, 你們測吧(充實的一星期又過去了)
13樓：吃不起瓜的旁觀者
上線時發現bug，為了上線驗收要錢提供乙個臨時方案。
其實，最後就成了最終最優方案。
臨時方案也沒啥問題，更改後出問題誰負責呢？
╮(︶﹏︶")╭
14樓：
第一周：專案已完成10%（實際完成5%
第二週：專案已完成50%（實際完成10%
第三週：專案已完成90%（實際完成30%
第四周：專案已完成95%（實際完成60%
第五周：專案已完成99%（實際完成80%
第六周：專案已完成99.9%（實際完成90%第七周：專案已完成100%（實際完成99%
產品經理們最常說的 謊言 有哪些？
一句話的需求。做乙個乙個月工期的系統，整個文件通篇不到，原型也是從現成的應用截圖來的。然後你去跟她確認乙個需求，她自己找了半天，然後指著倆字，接著神級腦洞的扯上關係，最後還說，你看我這裡寫的很清楚呀，你們程式設計師能不能認真看需求文件。真是斃了狗了。 然後，研發的同事很不情願的答應了，產品妹子笑眯眯...
做科研最常說的 謊言 有哪些？
國外不太清楚國內的科研一般可分為造假或者很水 科研本身就是研究人員自己都不信的謊言但是國家的錢你花不出去也顯得不太好不是不過最尷尬的還是總有一些人喜歡拿著篡改資料後的研究成果去給人科普所謂的科學真相 就我個人的話應該是靈光乍現想到乙個idea 然後自己對自己說這個厲害了這個厲害了太創新了 文獻一查可...
有哪些同學是大學畢業後轉行當碼農，如何接觸並找到工作的 直接找培訓機構可行嗎？
思遊 直接找培訓機構靠譜，找個靠譜的培訓機構。不要幻想找個班就什麼都學會了。不管在大學還是在培訓機構，都是師傅領進門，修行靠個人。當碼農對於自學能力是有較高要求的。現在網路上資訊這麼多，肯定主要靠自學！在乙個培訓班裡能學到是 獲得知識，建立信心，拿到乙隻文憑作為找工作的敲門磚，認識幾個志同道合的朋友...