第1章程序員的職業規劃 1
IT從業人員的職位介紹 1
開發人員 1
測試人員 3
產品經理 4
UI設計師 5
運維人員 5
用戶體驗師（UE/UX） 6
技術經理 6
架構師 7
如何選擇編程語言 8
做Web后端開發建議選擇Ruby 8
做Web前端（H5）建議使用Vue.js、React 8
做移動前端（App）建議使用原生語言和ReactNative 9
理想的職業發展路線 10
第一階段：新手 10
第二階段：熟手 11
第三階段：技術經理 11
第四階段：創業公司CTO或大公司技術頂層 11
程序員的基本門檻 11
英語必須好 12
思維清晰、反應敏捷 13
表達溝通能力強 14
程序員的進階門檻 15
具備領導氣質 15
技術過硬 16
IT從業人員的去路 16
繼續做IT 16
小幅轉行 17
大幅轉行 17
不看好的職業：測試、運維、架構師 17
測試 17
運維 18
架構師 21
軟件培訓機構 21
確實能改變少部分人的命運 21
在一定程度上推進了國內技術的發展 22
培訓機構之痛 22
第2章程序員的職業成長建議 25
務必有技術博客 25
表達能力得到極大提高 25
技術可以得到積累 25
個人博客是一張好名片 26
不要敝帚自珍 26
要會與人和睦相處，不要任性 27
控制好自己的脾氣 27
越牛就越謙遜 28
溝通能力是立足社會之本 28
溝通能力很重要 28
千萬不要性格內向 29
任務沒能力完成要勇敢地說出來 30
小心程序員的膨脹期 30
不要因為被上家公司坑過就對下家公司抱有成見 31
不要論戰 31
使用傳統編程語言的人特別容易心態不好 33
高發誘因1：過于底層的語言 33
高發誘因2：開發人群的職業年齡是2~4年 34
不要踢皮球 35
會錯失機會 35
會使人緣變差 36
會使人平庸 36
要抓住一切機會帶團隊 36
一個人做不成事情 37
帶團隊能讓人開闊眼界 37
具有帶團隊的經驗能讓人更好地在社會中生存 38
帶團隊是職業生涯注定的方向 38
要有良好的心態 39
每天都要學習 39
不要淪于平庸 40
工作就是最好的學習機會 41
辦公室沒有政治 42
不要參與公司的八卦 42
正確面對公司的裁員 43
敏捷方法論 44
頻繁交付、小步快跑 44
能自動化的都自動化 45
必要的測試 45
每日例會 45
要培養成學習型團隊 46
良好的程序員工作習慣 46
晚上十點前睡覺 47
健康問題：不要總低頭弓背 48
離開顯示器和手機才是休息 49
不要沙發椅，要坐硬板凳 49
顯示器要有護目屏 50
程序員的工作組成 51
程序員的工作不是一直在寫程序 51
技術經理 51
程序員要走出去 52
性格內向 52
過分細膩 52
容易自傲自大 52
不要坐井觀天，要多看看外面的世界 53
規劃好業余生活 55
不要愛上旅游 55
不要接私活 55
利用業余時間做教學 56
中國IT公司的特點 56
技術實力層面 56
人員的年紀差距 57
35歲開始失業 57
技術高層不懂技術細節 58
管理更加嚴格 58
國內軟件崗位的地域特點：北上廣深是絕對主力 58
讀書清單 60
《程序員修煉之道——從小工到專家》 60
《軟件工程的事實與謬誤》 61
《黑客與畫家》 62
《軟件隨想錄》 63
《人月神話》 63
《人件》 64
職業前輩的博客 64
第3章給程序員的技術建議 66
程序員如何提問 66
使用好鍵盤周邊 67
選擇什么編輯器 67
要有正確的鍵盤指法 68
好鍵盤很重要，它是我們的武器 69
合適的鍵盤布局 69
使用好“第六根手指” 70
如何使用快捷鍵 70
單鍵快捷鍵 71
兩鍵快捷鍵 71
三鍵快捷鍵 71
快捷鍵的思考 71
薄鍵盤和Mac鍵盤不適合程序員 72
程序員的理想裝備 73
大屏顯示器 73
機械鍵盤 73
游戲鼠標 74
大容量內存 74
固態硬盤 74
高速網速 74
版本控制工具 75
控制源代碼的必要性 75
歷史上的一些SCM工具 76
版本控制終極者：Git 76
在技術的天空中留下痕跡 77
必須有技術博客 77
必須要有StackOverflow的賬號 78
必須參與開源項目 79
絕對不要寫重復代碼 80
讓程序員喪失工作的興趣 80
讓程序難以修改和測試 80
讓人容易辭職 80
解決重復的原則：事不過三 81
命令行在大部分時候要優于圖形操作界面 81
幾個例外 83
操作系統的選擇：優先使用Linux 84
技術廣度比深度更重要 84
以性價比最高的方式點亮技能樹 85
如何學習多種技能 87
技術債 88
技術債的后果很嚴重 88
典型的技術債1：錯誤的底層架構 88
典型的技術債2：錯誤的技術實現 88
典型的技術債3：低劣的代碼質量 89
解決方案 89
一種高效的需求分析方法：可視化分析 89
用戶的需求特點：不明確 89
方法概述 91
具體方法 92
幾點注意事項 97
登錄頁面一般分成兩端 98
估算工作量 98
代碼質量 99
良好的命名是最好的注釋 99
為什么不要注釋 100
不要使用縮寫 102
慎用匈牙利命名法 102
廢代碼 104
看起來美好卻不實用的技術 105
屏幕自動適配 105
語言的國際化（i18n） 106
多數據庫的同時適配 108
其他 109
為什么要自己搭建博客 110
要學會分享和開放 110
博客是重要的名片和筆記 110
寫博客可以極大地提高表達能力 111
追求自動化 111
編譯的自動化 111
部署的自動化 111
測試的自動化 112
第4章如何管理技術團隊 113
基本的管理原則 113
就事論事 113
任務劃分得當、精確到人 114
公平公正 114
保持開放的氛圍 114
程序員的特點 114
容易驕傲 115
程序員之間的鄙視鏈 115
比較單純 115
有職業病 116
容易自我關閉 116
技術人員的性格特點 117
實力決定地位 117
誠實才會走遠 117
高壓政策下容易踢皮球 117
性格趨于內向 117
正能量與負能量 118
技術團隊的內部矛盾 118
程序員跟產品經理的矛盾 118
UI跟程序員和產品經理的矛盾 119
產品經理跟老板的矛盾 120
程序員跟測試人員的矛盾 121
程序員跟運維人員的矛盾 121
前端與后端開發人員的矛盾 122
招聘和培養新人 123
如何招聘新人 123
如何培養新人 126
如何對待老員工 127
老員工是公司的財富 127
老員工生產力可能是新人的10倍以上 127
尊重老員工的建議 128
要有領導藝術 128
給老員工成長的空間 128
如何識別項目毒藥 129
脾氣差并與同事發生過爭執的人 129
在代碼中寫過粗口的人 129
工作中喜歡抱怨的人 129
培養自我成長型團隊 129
做好知識分享會 130
鼓勵在項目中使用新技術 130
只招聘聰明人 130
讓團隊散架的因素 130
團隊毒藥 131
不公平的薪水 131
不開心的工作環境 131
絕對不要認為技術人員的生產力是固化的 132
問題1：出高價也招不到合適的人 132
問題2：就算招到也容易離職 132
問題3：人與人的工作效率很不一樣 133
第5章國內軟件開發之殤 134
行業弊端 134
軟件價格要么低得離譜，要么高得過分 134
存在欺騙和不信任的情況 136
有吃回扣的傳聞 137
程序員群體的心理狀態 137
不認權威，誰行誰上 137
清高、難以管理 138
容易跳槽 138
軟件開發的行業真相 138
需求方最關心的三句話 138
軟件項目成功率比較低 138
軟件開發工作量難以計算 139
軟件開發是重度自定義的 139
不存在萬能的系統 139
軟件的重用和細化粒度 140
國內軟件公司的特點 140
技術含量低 141
普遍英語不好 141
要么是外包公司，要么是互聯網公司 141
外包公司大部分都比較爛 141
大公司的軟件部門其實跟小作坊差不多 142
國內的程序員容易安于現狀 142
修改開源項目的風險極大 143
開源項目的風險 143
開源項目的特點 144
創業團隊務必要有CTO 145
CTO是技術團隊的組建者 145
CTO是團隊發展的土壤 145
CTO是團隊的舵手 145
CTO的困局 145
合格的CTO的標準 145
技術要全面 146
真實的CTO囧境 146
如何找到靠譜的CTO 147
通過技術圈的朋友來引薦 147
靠譜的CTO可遇而不可求 147
絕對不要找兼職的CTO 148
低工資留不住人 148
簡歷中的尷尬 149
團隊培養的途徑 149
把握好你的CTO 149
技術團隊要少而精 150
正視技術人員的作用 150
技術一般短期內被高估、長期內被低估 150
就差一個程序員了 151
好的程序員與差的程序員的差別 152
第一次和第N次的區別 152
好的程序員都是靠項目磨練出來的 152
程序員永遠會遇到新問題 153
核心技術變更得比較慢 153
二八定律 153
外包的亂象 154
行業門檻低 154
絕對不要找外地的承接方 154
絕對不要找太便宜的軟件承接方 155
絕對不要貪圖便宜 155
絕對不要找兼職的開發人員 155
經驗：明確互聯網在自己項目中的位置 156
經驗：一個靠譜的技術開發團隊的運營成本 157
經驗：外包項目與自己培養團隊的比較 157
經驗：如何保證你的項目進度 158
經驗：產品經理如何提需求 158
為什么好的程序員或者一流的技術人員難找 159
英語不好 159
人心浮躁 159
為什么程序員通常無法精通多個語言或者技術 160
傳統語言過于笨重 161
使用第三方包也很慢 161
傳統語言與現代語言的對比 162
自有團隊 163
開發初期的費用 163
自有團隊的好處 163
自建團隊的關鍵 164
如何招聘 164
從技術痕跡識人最靠譜 165
軟件與家裝的行業比較 166
都有復雜的流程 166
都是工匠行業，跟流程無關 166
不夠透明的因素 167
期待變革的步履蹣跚 168
需要用戶頻繁的反饋 168
基層員工水平參差不齊 169
這是一個不確定的行業 169
軟件工作量難以準確估算 169
腦力勞動難以衡量 169
工作量無法明確衡量 170
用戶的需求是不明確的 171
行業曙光1：全棧工程師 171
角色的緣起 171
溝通的成本太高 171
不好的流程會催生出壞人 172
不要把程序員分成后端和前端 173
全棧工程師的特點 174
實戰情況 176
有可能產生全棧工程師的技術背景 176
行業曙光2：乙方應該按時間收費 177
絕對不要按照模糊的需求來收費 177
可以按照項目收費 177
用時間給程序員估價是合理的 178
死亡案例 179
一句話需求 179
超過半年的交付周期 180
不合理的價格 180
層層轉包 180
不要頻繁見面 181
不靠譜的程序員 181
異地外包 181
用戶不切實際的過高期待 182
被人用現成的項目去套 182
外行人做的軟件公司必死 183
不要迷信高學歷CTO 183
項目失敗很傷人脈 184
不要迷信海歸 184
不要做人力外派公司 185
員工的歸屬感不強 186
招不到好員工 186
難以直接管理 186
小心花架子技術負責人 186
實戰經驗弱 187
學歷大部分很高 187
背景很高大上 187
結論 188
第6章軟件外包公司生存指南 189
接項目務必慎重 189
傳統公司的項目不接 189
甲方公司存在內部矛盾的項目不接 190
管理不規范的公司項目不接 191
不守時公司的項目不接 192
要回扣的項目輕易不接 192
互聯網公司的項目更舒服 193
外包公司永遠的痛點：要賬 193
永遠不要跟甲方撕破臉 193
跟甲方保持好關系 194
要賬要找對人 194
需求的特點 194
需求一定比想的要復雜 194
不要使用菜單式報價 195
需求是一定會變更的 195
需求不要只增不減 196
如何識別不可或缺的需求 196
軟件外包公司的宿命：倒閉或轉型 196
倒閉 197
轉型做產品 198
軟件公司老板的特點 198
招不到靠譜員工 198
留不住人 199
解決辦法 199