心得
這本書不愧是「Geek」所寫，看完後可以放心地說我不是Geek！因為大部分的內容對我而言都沒有實質幫助，書中許多章節對我來說多是廢話。本書也沒有嚴謹的架構，應是整理過去部落格或是定期文章而成，許多內容頗有「硬」寫之感。
以管理群像這個主題（P88）為例，列舉了五種管理人（質問者、修先排序者、隨機者、提問者、敵人），分別對他們的特質、開會習慣做分析，顯然低估了人的豐富性，並且這樣五個的分類也只是依據作者喜好而分。
當然像這樣的窮舉，偶爾還是有些提點作用，只是以整本書與有幫助的部分比例來說，實在懸殊，我會推薦資訊人
避開這本書，因為有更多值得參考「軟技巧」類的書，例如：軟技能代碼之外的生存指南 (Soft Skills : The software developer's life manual)或是程序員思維修煉（Pragmatic Thinking and Learning: Refactor Your Wetware ( Pragmatic Programmers )）。
筆記
（以下內容都有改寫）
P85 講真話：
是不是我們在跟人對話時，即使很順利，仍忽略掉了什麼，可以談些什麼話題，即使微不足道都能令這段對話更有價值？可能是對同事、朋友或家人（尤其父母）。
在停止找藉口後，我們有沒有沒採用那些腦中一閃而過更有價值的話題？而不是說些廢話。每次開口說話時，
我們都有機會創造某些東西，要由這個角度切入，而不是誰是誰非那種情緒性的藉口。
P105 嘆息（本書最棒的章節）：
當危機出現時，如果缺少溝通的平台，會使困惑誕生於團隊，人們可能：
1. 缺乏有力資訊下，腦補資訊空洞，試圖建立看似有結構的東西，但通常只會讓情況更混亂。
2. 雖然成員彼此不停討論危機，但並沒有創造新的內容，只是對危機的反雛；如果只是討論危機如何如何，
不過是減輕內心的焦慮，對危機處理沒有任何幫助。
3. 缺乏溝通，所有人又都要知道所有事情，導致大家想：我要知道一切，並且我也有特別的東西想加進去，而且最好能讓我這樣做！
作者提出三種會議解決危機：
1. 與下屬1:1會議：你在擔心什麼？我擔心的是這些。討論...（即使你跟工作夥伴再熟，1：1會議都不該被省略）
2. 工作人員會議：我們在何處？我們要做什麼？我們要怎麼做。專案初期重點擺在設計，後期擺在產品品質。
3. "看我們建造了什麼"會議：在週五下午四點舉行，呈現大家進展，讓大家知道即使危機產生，我們也做了這麼多（產生正面回饋）。
如果這類會議能定期開，有以下好處：
1. 讓所有人知道溝通隨時存在，建立信任
2. 讓創意得以在非會議期間自由發揮（不會被干擾）
這樣的概念其實跟Scrum很像，但Scrum要運行的順，實在很吃公司文化與產品內容。
P128 關於信任課題：
即使與人稱兄道弟，都該跟工作夥伴保持一個適當的距離，
該成為別人信任的夥伴，並且贏得尊重，目標是建立一套關係，彼此信任對方的可靠、真誠、能力與堅強。
作者透過一種BAB（後巷橋牌）的牌類遊戲建立工作夥伴彼此的信任，創造一種安全的環境，即使在尚未合作狀況下，彼此產生信任關係。
