有一部分程式員中的老司機，他們善于找各種借口，少幹活，少背鍋，多拿錢。但是，更多的程式員坦誠、直白、意氣用事。
那些年吹過的牛逼都實作了嗎？還是随風而去？
這個功能簡單，一天就能搞完
程式員拿到一個新功能，心裡暗暗發笑，這劇情我見過啊。于是脫口而出，這功能簡單，一天就能做完，明天上線肯定沒問題。
結果，眼看着到自己設定的截止日期了，還有一部分代碼沒有寫完，怎麼辦？
很簡單啊，又不是生死狀，又不要命。解決辦法很簡單，加班～～～
程式員，那些年吹過的牛逼，最後都自己加班了。
這段代碼肯定沒bug，我都測試過了
功能開發完了，拿去測試吧，拿去玩耍吧，上線吧，部署吧，發給客戶吧，肯定沒問題的。
結果，很多時候還沒釋出。要麼測試發現bug，要麼産品發現bug，要麼老闆發現bug。
你的第一反應就是：是特麼你們不會用老子開發的功能吧？你樂呵呵的看着bug複現，怎麼辦呢？
很簡單啊，緊急修複bug，重新釋出。時間來不及了？加班啊～～～
我用的是最現在最流行的技術，某某大公司也用這個
在技術讨論會上，你侃侃而談，我精心設計的前後端分離的架構，我使用了現在最流行的界面庫，我們用的技術某某獨角獸公司都在使用，肯定是最好的。
結果呢，使用的技術太新。github上很少有相關的開源項目，stack overflow上很少有這方面的問答。你被一個問題搞的昏天暗地，隻能默默的看官方文檔，而且是英文的（這是好事兒）。
啊？項目着急上線怎麼辦呢？加班啊～～～
重構代碼，很快就能完成
何為code refactoring
之前為了快速疊代，忽略了代碼的結構和品質。正好最近這兩天沒有什麼新功能開發，我要重構一下現有的代碼，絕對沒問題。
結果呢，兩天的空窗期沒搞定。明天就要開發新的功能了，怎麼辦呢？加班啊～～～
向外行介紹程式員工作的複雜程度
在工作中經常能聽到這樣的話「不就加個按鈕麼？怎麼要做兩天時天？」。那麼，作為程式員如何解釋自己的工作複雜度呢？
如果你的老闆是技術出身，那你很慶幸，他能了解你實作一個小小功能，修改一個小小功能所付出的辛苦勞動。
如果你的老闆不懂技術，也許你就要無窮無盡的加班了。給你的忠告就是：做正确的事兒，等着被開除。這是一位谷歌工程師說的話。
如果你的産品經理懂技術，那麼你既是幸運的也是不幸的。
幸運的是，他可以了解程式員工作的複雜度。但是“不幸”的是，你再也不能為了偷懶找借口。
當産品經理提出一個方案時，你再也不敢堅定地說“技術不可行”。因為你害怕産品經理自己寫好了代碼給你，那是多麼尴尬的境地。
下面是 channing walton 的用泡茶的例子來解釋，非常形象。
請他們描述泡出一杯茶需要哪些步驟，他們會這麼說：
燒水
把茶葉放到茶壺裡
水燒開後倒入茶壺
等待5分鐘
把茶倒進杯子
加牛奶
喝
現在，有趣的開始了。你要開始問這樣的問題:
燒水?
水哪來的？
熱水壺在哪裡？
你怎麼把水倒進熱水壺？
你怎麼知道熱水壺壺裡要倒多少水？
如果沒有水/熱水壺/電怎麼辦呢?
假如加水傳感器失效怎麼辦?
假如煮水傳感器失效怎麼辦？
茶葉放到茶壺裡?
茶壺在哪裡，如果沒有茶壺怎麼辦？燒水之前我們應該考慮到這些問題嗎?
茶葉在哪裡，要用哪一種茶葉？我們是否應該先問清楚，或許如果沒有對應的茶葉，我們甚至都不應該開始泡茶?
關于加水和傳感器也可以有類似的問題要問
倒開水?
你确定水已經開了麼？你怎麼能確定“倒水”的機器從熱水壺那收到“燒水完成”的信号呢?
你如何確定倒水的機器知道熱水壺在哪裡?
如果熱水壺在倒水的過程翻了怎麼辦呢?
程式員代碼送出中的罵聲
正如你工作中看到的，寫代碼會讓你罵罵咧咧，經常爆粗口。
另外有資料統計，寫 c++ 程式，會比寫 php 或 python 程式所遭到的罵聲更多。
andrew vos在找一個周末項目，于是決定在 github 上抓取100百萬條送出資訊（commit），并掃描其中的髒話。
而且程式員最喜歡的一句是：
“去tmd，咱們就這樣釋出。”