- 寫規格的人，必須完全掌握你的規格，與關聯到的所有實作細節、邏輯
- 各領域中最好的人才不會出現在人力市場，而且他們花在「應徵」這件事上的時間很短
- 優秀的開發者想要的是什麼，想在什麼工作環境下做事，喜歡什麼？又討厭什麼
- 私人空間可以增加程序員的生產力，提高軟體開發效率
- 組織內部如何看待程序員，只是打字員，還是重要人才
- 聰明，且能把事情搞定，不是怪胎
- 別讓自己的「建議」被解讀為「命令」，讓其對在自己專精的領域內做決策
- 不搞不正常的政治
- 讓開發者做有趣的工作
- 年輕的程序員會被意識形態吸引
- 希望自己的工作是有意義的
- 培養程序員的認同感
- 薪資公平，避免同工不同酬
- 薪資必須要有（同業中）競爭力
- 讓大家做你想做的事情
- 指揮及控制管理法
- 經濟學101管理法
- 認同管理法
- 不管你說什麼，照做就對了，不服就斥責、處罰
- 聰明的人不喜歡被下自以為是的指揮、命令，會不爽
- 軟體開發細節太多，管理層淪為打了就跑
- 知道最少的人反而是做技術決策的人，而非開發者
- 讓他們向士兵一樣照命令做，尤其對優秀的開發者到哪都可以工作，會留不住人
- 付錢讓人們去做本來就想做的事，外在動機就取代了內在動機，降低了想把事情做好的渴望
- 外在動機：賺額外的錢
- 內在動機：把程式寫好
- 導致：我不想賺那額外的錢，程式沒寫好，搞的自己花超多時間除錯->寫出破綻很多的程式
- 或導致：我想賺額外的錢，所以我會花額外的時間把程式寫好，但一旦你抽掉這個額外的錢，我就不願意花額外的時間做好這件事
- 找出能換取你給予得東西極大化的方式，例如讓「錯誤 (看起來) 很少」，任意掩飾所有的錯誤，換取獎勵，卻導致產品不穩定，但你本身給這個獎勵的初衷是「錯誤很少 = 產品要穩定」
- 讓大家認同你想達到的目的
- 讓大家對同事都有某種忠誠與承諾感
- 提供資訊，讓人們將組織駛向正確方向
- 打好寫程式的基礎
- 因為找不到現成的軟體而雇用內部程序員（你）開發內部軟體，你永遠無法用正確的方式做事，只能用最便捷的方式來做，因為「這很花錢」
- 只要程式夠好夠用，你就要住手了
- 一旦核心功能完成，後續投入都沒有回報，沒有商業上的理由要去改善它
- 能夠清楚的寫好技術主題文章，是底層程序員與領導者間的差異
- 寫作能力、鍛煉大腦內對往後有幫助的能力
- 學會寫作
- 學會C
- 非專業領域的課（覺得無聊）不要一開始就排斥，每個工作的都有無聊的時候，很多公司不會想請只想做有趣好玩事情的人
- 學會個體經濟學，提升個人價值
- 寫大量的程式
- 人們會選擇他們熟悉的（風格或設計）系統
- 想要創造一份有用的軟體，你必須爭取每一個修正、每一個功能，還有每個小小的妥協，努力幫助多一個人跨越學習曲線
- 每天進步一點、把每件事都做更好一點，就是多一寸進展
- 必須對要做的事情全盤清楚，不要掉入過度自信的情況，大腦會誤以為對事情已經非常清楚，甚至都不寫規格直接開始寫程式
- 唯一比軟體設計困難的事情，就是讓團隊一起設計軟體，你還沒設計好就不要僱用程序員
- 選項越簡單易懂，才是越好的設計，但軟體設計往往希望提供越多越彈性的選項，讓使用者反而不明白用途發生選擇障礙
- 可用性不是隨時隨地都是必要的
- 人與人互動的介面：社會性介面
- 人與軟體互動的介面：使用者介面
- 除了做好使用者介面，社會性介面才是最重要的，如果你的軟體無法顧及到人，與溝通對象，使用者介面再好也沒用
- 考慮文化與人性
- 防禦性設計，例如垃圾信阻擋，讓信箱更好用
- 工作使用的輔助軟體，常常因為要求所有人同時改變工作方式，而無法持續。...設計成刻意讓產品在團隊中只有一人參與時也仍然有用，在另外大量設計其他功能，鼓勵把軟體散布給團隊其他成員，直到所有人都在使用
- 論壇設計重點，放在增加交談意願，免註冊開放留言可以起鼓勵效果
- 依照原貼文發佈時間排序，而非最後更新時間排序，可讓閱讀者有順序的看文章，不用一直去看到舊的文章
- 有新的回覆的文章可以藉由把回覆數量掛在 url 上，瀏覽器就會因為數量有變化而判別成沒有點過的連結
- 回覆文章的按鈕或開新文章的按鈕都放在最後一個留言下面，強迫使讀者先看完留言再看看需不需要開新文章或留下留言
- 不做確認步驟是因為大多數人編輯時就會確認文章，且少了確認動作反而使人更謹慎的發出留言
- 不顯示回覆對應的原文，是為了讓閱讀更流暢，不強迫使人一直重讀原文，太繁雜
- 消除空餐廳效應，如果你的網站都沒人留言，會導致沒人想逛，反而會去逛一些文章質量差，但有人流的網站
- 就像首頁提供的敲客服，即使你不是會員也可以使用客服系統
- 制定規則只會侮辱多數守法公民，並不能阻止低能兒認為自己不可能違反規則，或不在意自己有無違反規則
- 要讓軟體滿足所有版本或標準格式是不可能的，舊有軟體跨到新建軟體，會有不相容的問題，那所謂的標準格式無法通用支援新舊軟體上
- 略，這章還讀不出想表達什麼
- 為了賺錢投入人力與成本，做能賺更多錢的部分，而非一味做自己想做的部分
- 使用工具輔助訂定時程，逐步掌握如何預測準確的時程
- 略，這章還讀不出想表達什麼
- 了解第一級函數的用法，可讓你的程式有更多手段，設計具擴展性、更抽象的邏輯結構，更彈性且易於重用
- 學會如何分辨「乾淨」或「髒」的程式碼
- 程式員層級
- 你不知道「乾淨」跟「髒」有什麼區別
- 你對乾淨有粗淺的認知，主要以是否符合編程規範為準
- 你開始能嗅出藏在表面下不對境的蛛絲馬跡，你會察覺這是問題，並且找出來加以修正
- 你有計畫地架構程式碼，借助能察覺問題的靈眼，讓程式碼更正確
- 光看該行程式碼就足以看得出錯
- 通則
- 保持簡短的函數名稱
- 變數宣告的地方離使用的地方越近越好
- 不要讓左右括弧超過一個畫面
- 找出能讓錯誤程式看起來是錯的編程規範
- 略
- 在落後的軟體專案裡增加人力，只會讓他更落後
- 平凡人就是永遠唱不出天才隨時能飆出的那種高音：這不僅是10倍工作效率的問題，而是生產力尋常的開發者，永遠也飆不出製作優秀軟體所需要的那種高音
- 頂尖的工作環境->頂尖的程序員->頂尖的軟體->賺大錢
- 辦公室應該是個窩，辦公室應該比一般程序員的住家更棒
- 略
- 略
- 重構，不要加入新功能，就算很小很小的功能也不要
- 系統隨時都能完全正常運作
- 技術 beta 與行銷 beta 是不同的，前者目的是找出問題，並持續得到意見回饋，後者是軟體的搶鮮版，針對的是媒體與大客戶
- 每件事都用兩種方法修正
- 表相而即時的辦法，與思考更深層讓問題不再發生的解決方案
- 「技術支援人員」須能直接接觸「開發者」，比較貼近問題進而修正使其不再發生
- 建議吹掉灰塵
- 有客戶抱怨鍵盤不會動，客服不該直接請客戶檢查是否接頭沒接好（讓客戶覺得自己被當成白痴），應該換個說法，例如可否幫我重新拔掉接頭、吹掉灰塵，再連接回去，因為灰塵可能會導致接觸不良，於是客戶就會發現其實是自己沒接好接頭，但不用觸怒客戶，問題一樣有被解決
- 讓客戶成為狂熱支持者
- 幫客戶吸收「因為客戶報錯需求導致產品製作錯誤」的成本，讓客戶覺得很溫暖，成為自己產品的推銷者之一
- 承擔指責
- 身為產品開發商，若有錯誤，需要有向客戶承認「是自己做錯」的擔當
- 背誦緩頰短句
- 不要被情緒左右而衝動出口怒言相向，趕走客戶，試著不經過大腦就說出「對不起，我們會改善，是我們疏失」等短句
- 練習表演木偶戲
- 跟客戶吵架，你永遠不會贏
- 要理解客人不是對你生氣，而是對就近代表公司的你（公司的木偶），對公司（產品開發商）生氣
- 貪婪讓你一無所獲
- 如果沒有讓你很快樂（產品不好用、不實用），我們不收你的錢，就算我們訂定的退款政策是90天不滿意可以全退，但91天、100天、150天，你感到不快，我還是退給你錢
- 附贈：為客服人員規劃職業前景
- 提供進修資金補助轉為技術開發者
- 略
- 列出所有功能按優先順序排列，每次時程延誤就把不重要的功能砍掉，確保出貨日不變
- 先行版避免大量宣傳，導致大多數人的第一印象都很差，無法挽回名聲
- 定價需要參照利潤，且不要考慮沈默成本
- 資本家會想要獲取消費者剩餘（對於那些願意付更多錢取得相同服務的人，因為你定價太低而不用付出太多金額就取得，差額即為消費者剩餘），所以出現區隔訂價
- 未來收益流入的淨現值最大化（淨現值是估算現在的金額，在幾年後根據年利率而折算的結果）
- 現金儲備一直為正值
- 黑天鵝孤立點，指很少很少很少很少，罕見的突發事件
- 甜蜜點，指綜合各種因素下的最佳方案
- 如果你正在做某些只針對單一客戶的事情，表示你的業務不受控制
- 不要因為你「遲早都要完成」就去先做目前當下不是最重要、最優先的功能，會吃掉你現在的時間