程序員們，還記得那些年你們吹過的牛X嗎？—愛創課堂

有一部分程序員中的老司機，他們善於找各種借口，少幹活，少背鍋，多拿錢。但是，更多的程序員坦誠、直白、意氣用事。

那些年吹過的牛逼都實現了嗎？還是隨風而去？

這個功能簡單，一天就能搞完

程序員拿到一個新功能，心裡暗暗發笑，這劇情我見過啊。於是脫口而出，這功能簡單，一天就能做完，明天上線肯定沒問題。

結果，眼看著到自己設定的截止日期了，還有一部分代碼沒有寫完，怎麼辦？

很簡單啊，又不是生死狀，又不要命。解決辦法很簡單，加班～～～

程序員，那些年吹過的牛逼，最後都自己加班了。

這段代碼肯定沒bug，我都測試過了

功能開發完了，拿去測試吧，拿去玩耍吧，上線吧，部署吧，發給客戶吧，肯定沒問題的。

結果，很多時候還沒發布。要麼測試發現bug，要麼產品發現bug，要麼老闆發現bug。

你的第一反應就是：是特么你們不會用老子開發的功能吧？你樂呵呵的看著bug復現，怎麼辦呢？

很簡單啊，緊急修復bug，重新發布。時間來不及了？加班啊～～～

程序員，那些年吹過的牛逼，最後都自己加班了。

我用的是最現在最流行的技術，某某大公司也用這個

在技術討論會上，你侃侃而談，我精心設計的前後端分離的框架，我使用了現在最流行的界面庫，我們用的技術某某獨角獸公司都在使用，肯定是最好的。

結果呢，使用的技術太新。Github上很少有相關的開源項目，Stack Overflow上很少有這方面的問答。你被一個問題搞的昏天暗地，只能默默的看官方文檔，而且是英文的（這是好事兒）。

啊？項目著急上線怎麼辦呢？加班啊～～～

程序員，那些年吹過的牛逼，最後都自己加班了。

重構代碼，很快就能完成

何為Code refactoring

Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.

之前為了快速迭代，忽略了代碼的結構和質量。正好最近這兩天沒有什麼新功能開發，我要重構一下現有的代碼，絕對沒問題。

結果呢，兩天的空窗期沒搞定。明天就要開發新的功能了，怎麼辦呢？加班啊～～～

程序員，那些年吹過的牛逼，最後都自己加班了。

向外行介紹程序員工作的複雜程度

在工作中經常能聽到這樣的話「不就加個按鈕么？怎麼要做兩天時天？」。那麼，作為程序員如何解釋自己的工作複雜度呢？

如果你的老闆是技術出身，那你很慶幸，他能理解你實現一個小小功能，修改一個小小功能所付出的辛苦勞動。

如果你的老闆不懂技術，也許你就要無窮無盡的加班了。給你的忠告就是：做正確的事兒，等著被開除。這是一位谷歌工程師說的話。

如果你的產品經理懂技術，那麼你既是幸運的也是不幸的。

幸運的是，他可以理解程序員工作的複雜度。但是「不幸」的是，你再也不能為了偷懶找借口。

當產品經理提出一個方案時，你再也不敢堅定地說「技術不可行」。因為你害怕產品經理自己寫好了代碼給你，那是多麼尷尬的境地。

下面是 Channing Walton 的用泡茶的例子來解釋，非常形象。

請他們描述泡出一杯茶需要哪些步驟，他們會這麼說：

燒水

把茶葉放到茶壺裡

水燒開后倒入茶壺

等待5分鐘

把茶倒進杯子

加牛奶

喝

現在，有趣的開始了。你要開始問這樣的問題:

燒水?

水哪來的？

熱水壺在哪裡？

你怎麼把水倒進熱水壺？

你怎麼知道熱水壺壺裡要倒多少水？

如果沒有水/熱水壺/電怎麼辦呢?

假如加水感測器失效怎麼辦?

假如煮水感測器失效怎麼辦？

茶葉放到茶壺裡?

茶壺在哪裡，如果沒有茶壺怎麼辦？燒水之前我們應該考慮到這些問題嗎?

茶葉在哪裡，要用哪一種茶葉？我們是否應該先問清楚，或許如果沒有對應的茶葉，我們甚至都不應該開始泡茶?

關於加水和感測器也可以有類似的問題要問

倒開水?

你確定水已經開了么？你怎麼能確保「倒水」的機器從熱水壺那收到「燒水完成」的信號呢?

你如何確保倒水的機器知道熱水壺在哪裡?

如果熱水壺在倒水的過程翻了怎麼辦呢?

程序員代碼提交中的罵聲

正如你工作中看到的，寫代碼會讓你罵罵咧咧，經常爆粗口。

另外有數據統計，寫 C++ 程序，會比寫 PHP 或 Python 程序所遭到的罵聲更多。

Andrew Vos在找一個周末項目，於是決定在 GitHub 上抓取100百萬條提交信息（commit），並掃描其中的髒話。

而且程序員最喜歡的一句是：

「去TMD，咱們就這樣發布。