從小工到專家這本書以幽默風趣的語言向我們闡述其程式設計觀點，書中說到我們不應當因為害怕受到處罰，而沒有向上級匯報情況，更不要不好意思提出要求。只有積極的去解決問題才是最好的處理方法。但是匯報也不是一出問題就去匯報的，而是要在你已經嘗試了所有可能的方法，結果都沒有解決，在進行匯報的方式。其次就是提到了對**的修改，沒有乙個人願意在修改**的時候去改動那些寫的很完美的**。但是正如為了避免踩髒地毯而耽誤滅火的富豪一樣，不願意改動那些認為完美的**，只會導致產生的損失會逐漸的增加。還有就是借用石頭湯的故事，說明了如何領導組員進行更好的分配，正如石頭湯故事中的劇情一樣，我們大可以使用加上什麼什麼會更好來代替你要做出什麼什麼的話語，這樣更能有效的得到預期的結果。相比較而言，從小工到專家這本書與其說是一本程式設計思想書，倒不如說是一本描述程式設計師生存之道的書籍，其中不僅有程式設計之類的思想，還有一些領導能力和領導技能的培養。通過閱讀第一章，我從中學到了很多東西，很多都是關於在實際工作中如何提高自己的能力，減小損失，能夠更有效的取得預期的成果。
要與工匠一樣，想著定期增添工具，要總是尋找更好的做事方式。
要樂於超越信成開發環境ide所施加的種種限制。
程式設計師整天與編輯器打交道，一定要把編輯器用到極致，選擇強大的編輯器並用熟它！
曾經想學emacs，但最終放棄，因為我的常用的開發工具是visual studio，在這裡面使用emacs命令是一種痛苦，大量的ctrl,alt組合鍵與windows中的常用命令嚴重衝突，最後不得不回到vim編輯器來，幸好在visual studio中有好用的vim外掛程式，並且以前的許多ctrl組合命令仍然可用。
即使團隊裡只有你一人，也是使用原始碼控制系統。
以前用過vss，後來換過svn，還試過git，對我來說svn已足夠。
遇見bug的第一反應是「那不可能」，不要把情感浪費在這上面，它不僅可能，而且已經發生了。
首先把編譯器的編譯級別調到最高。
當你能夠重視這個bug，可能就快發現它發生的原因了。
bug可能會出現在作業系統、資料庫、編譯器中，但這不應該是你的第一想法。
修正bug後，想一想：以前為什麼沒有發現這個bug?是不是可以改進單元測試來發現這個bug?如果查詢這個bug花了很長時間，問問自己為什麼，下一次是不是可以更快地修復類似的bug?
在工作中我們總會遇到難以解決的難題，本書給我們提供的乙個思路是重要的不是你在盒子裡思考，還是在盒子外面思考，而在於找到盒子-確定真正的約束，詳細一點的解釋就是面對棘手的問題時，列出所有在你面前的可能途徑，不要排除任何東西，不管它聽起來有多無用或愚蠢。然後逐一檢查每一項，並解釋為何不能採用某個特定的途徑。有時候你會發現，自己在處理的問題似乎比你以為的難得多，這種時候很可能你已經走錯了路，你需要回退一步，問問自己有沒有更容易的解決辦法。
11月從小工到專家讀後感（二）
按合約設計 感覺這個dbc限制太嚴格了，有點受不了。這樣做是否值得？代價是不是有點大？然後按照合約去進行設計。死程式不說謊 早崩潰。發現問題，就要讓它在問題的現場崩潰，不要跑到呼叫的棧頂再告訴你發生了什麼。怎樣配平資源 分配資源的例程要負責釋放它。以與資源分配的次序相反的次序解除資源的分配。因為先後...
從小工到專家讀後感4
第四章注重時效的偏執 you can t write perfect software 你不可能寫出完美的 注重實效的程式設計師連自己也不信任。知道沒有人能編寫出完美的 包括自己，所以注重實效的程式設計師針對自己的錯誤進行防衛性的編碼。按合約設計 dbc軟體設計中為了確保軟體模組的權利與責任，以確保...
從小工到專家讀後感3
第三章為基本工具。除錯的第一準則 不要慌 如果你目睹bug或見到bug報告時的第一反應是 那不可能 你就完全錯了，乙個腦細胞都不要浪費在 但那不可能發生 起頭的思路上，因為很明顯，那不僅可能，而且已經發生了 在除錯時小心 近視 要抵制只修正你看到的症狀的迫切願望 更有可能的情況是，實際的故障離你正在...