在怨天尤人之前，先努力把你自身的問題解決了
你寫的程式出問題了，那絕對是你的錯，即使問題出在第三方，你仍要徹底排除自身的代碼問題，然後提交錯誤報告。
故事 : select 有問題
select 有問題，是指有個系統的資料存取有問題，該程序員認為自己的程式沒有問題，所以用了各種方式想要釐清問題，但最後都徒勞無功。直到最後，閱讀 select 文檔，花了幾分鐘發現並改正問題。所以 select 有問題 成了一個善意的提醒，在指責其他問題前，先檢查自己的部分。【你必須總是假定問題出在你的代碼身上，並為它的故障負上全責】。
想知道真正的敵人嗎?去照照鏡子
每個程序員都想要把自身所學都貢獻到程式裡面，但是你可能會過度設計、失控。請惜墨如金，盡量簡潔，每個方案都是折中方案，控制自己不要在裡面寫一大堆代碼。
避免寫註解 – 讓程式碼就是最好的註解
很明顯，如果程式沒寫註解，沒有人看得懂，如下所示
r = n / 2;
while (abs(r-(n/r)> t))
{
r = 0.5 * (r + (n / r));
}
System.out.println("r = " + r);
在增加註解後，可以讓它更明確的知道用途
//用 牛頓-拉夫遜 近似法求 n 的平方根
r = n / 2;
while (abs(r-(n/r)> t))
{
r = 0.5 * (r + (n / r));
}
System.out.println("r = " + r);
只是你可以更進一步，可以將它重構，移除註解，讓程式碼就是他最好的註解
private double SquareRootApproximation(n)
{
r = n / 2;
while (abs(r - (n / r) > t))
{
r = 0.5 * (r + (n / r));
}
}
System.out.println("r = " + SquareRootApproximation(r));
註解是支撐程式碼的枴杖，你應該在開發時，專注於程式碼上，想盡辦法讓你的程式碼讓你的夥伴可以理解，真的沒有辦法，才加上註解。
學會讀原始碼
客戶不會在乎是誰失誤，他們只想要你找出問題，並把它解決。在你說這是函式庫，無法修改時，何不先試著讀讀看這些原始碼，追蹤錯誤。
無論它看起來多可怕，也不管它會把你帶向何方，跟它去吧!
閱讀別人原始碼是一個技能，但沒有人是因為樂趣而去讀的。
有問題，問橡皮鴨
如果你還沒有一個程式員夥伴，實驗證明，當你有解不開的問題的時候，對著橡皮鴨講話，把你的問題告訴他，通常，你的問題會迎刃而解。對著鴨子講話，把問題明確表達出來，你將會意識到你犯了什麼錯誤，此時問題不再是問題。
當你提出正確的問題時，差不多就已經把問題解決了。
除非創意能夠被執行，否則它一文不值
與其擔心創意是否夠出色或是否會不會被抄襲，不如擔心能執行得多好。如果你把創意給一個普通團隊，它會把它搞砸。如果你把它給一個好的團隊，它會完善它，甚至拋棄它，然後改進出一個更好的。但是如果你不執行，他就是一個空談。
電梯測試 – 是你的團隊能否在60秒內，告訴一個外行人，它們在做甚麼?及為何要做這個?
因為各領域都會有自己的術語與常識，但這些過度包裝的語言在外行人身上是聽不懂的。另外，當你在問問題時，回答的程序員未必能直接回答出你要的答案。
豐田的五個為什麼，便是認為五個 Why 才能問出答案。
我的汽車無法啟動。（問題）
為什麼？：電池電量耗盡。（第一個為什麼）
為什麼？：交流發電機不能正常工作。（第二個為什麼）
為什麼？：交流發電機皮帶斷裂。（第三個為什麼）
為什麼？：交流發電機皮帶遠遠超出了其使用壽命，從未更換過。（第四個為什麼）
為什麼？：我一直沒有按照廠家推薦的保養計劃對汽車進行過保養和維護。（第五個為什麼，根本原因）
設計包裝盒
假設做的產品可以放到盒子裡，請團隊思考產品願景，設計包裝盒的正面跟背面
- 產品名稱
- 產品特性
- 產品需求
- 圖或畫
- 詳細說明
- 等等
讓性能成為一種驕傲
Google 發現 0.5秒的延遲將會導致20%的流量下降，但如果要上CDN 應該也是最後手段，如果用戶需要在這個”洞”等上整整一秒，那應該是一個超級大 Bug。