這次閱讀中體會最深的莫過於奇客和狗，作者透過Chandler狗、Cosmo狗以及各種狗來類比OSAF開發的專案，前面兩種都是拉布拉多獅子狗，文章這樣描寫這兩種狗，“它們是好寵物：‘和其他狗類融洽相處’”、“非常聰明，快活而友善。能快速學會不常見或特殊的技能。活躍，有時顯得滑稽。如果管束不嚴就會戲弄主任”，這樣一種“狗”似乎更像是Chandler的真實寫照，如果管束不嚴就會戲弄主人，是啊，沒有嚴謹的要求和恰當的決策，Chandler的開發過程才會如此的坎坷吧。
卡普爾和開發者們總是抱著改變世界的想法前進的，他希望Chandler成為一種全功能的個人資訊管理器，也希望它能成為一個“可擴充套件開發者平臺”，使得程式設計師可以任意擴充Chandler的功能，“能二者兼得嗎？”，這也是值得我們反思的問題。
雖然理想很豐滿，但是更多時候我們是沒辦法做到二者兼得的，既然不能二者兼得，又免不了做出選擇，而這些選擇總會讓產品的某一發展前景被扼殺。在無法做出選擇的時候，Chandler選擇了替換新的產品經理，似乎這樣一種改變就可以拯救Chandler的命運，但是沒有考慮到，我們的主人公之一——卡普爾，仍舊秉持著“完美”的理念去做Chandler，去暢想Chandler。
文章中提到一項調查，調查顯示超過四分之三的IT專業人士偏愛考慮後做決策，而只有23%的人偏愛憑感覺決策，多數程式設計師的共事者都瞭解到，敲程式碼的人更像是理性的獨行俠，他們的行為特徵被形象的比喻成輕度自閉症，而這樣一個特點使得他們不懂得如何打造能完成人類使用者設定目標的程式。
所以又引出了高過其他程式設計師的程式設計師不同於普通程式設計師的地方——交流
如果說程式設計師與程式碼之間是狗主人與狗的交流，那麼程式設計師與使用者之間更像是狗主人與鄰居的交流，身為一個鄰居，你要清楚鄰居是否喜歡狗，是否喜歡養狗，又是否喜歡狗的某些行為，討厭狗的某些行為，你要讓你的狗儘量在鄰居面前討喜，而不是僅僅依照自己的喜好和想法來培養和訓練你的狗——這是我的觀點。
文章中不僅提到了狗和養狗人的概念，還出現了狗食的說法。據說很多軟體公司一個不成文的規定就是，開發者必須使用自己正在做的產品，即，吃自己的狗食。現在轉念一想，吃自己的狗食確實是開發中發現bug和缺陷的手段，只有親身體驗，才能對自己做出來的產品有個完整的認識，只有吃過自己做出來的狗食，才知道味道怎麼樣，而不是隻管做，不管味道。
在我第一次的開發工作中，就沒有充分考慮使用者的意見和建議，產品成型後，使用者給的反饋並不是很好，產品雖然沒有一些明面上的bug，但是使用者對於一些功能的設定並不滿意，這也就導致了產品的失敗。首要原因就是開發設計之初沒有深入使用者，如果再次開發，我會更多的詢問使用者的想法，從使用者出發決定產品的功能。