持續更新，最近更新時間：2019.10.31
簡介
我在某平臺上學習10x程序員工作法，特此記錄下我結合工作中實際情況對10x程序員工作法的理解與總結
目錄頁面
開篇詞
作爲程序員，我們將其看作一個值得全情投入的職業，希望能夠把精力放在設計算法、改進設計、優化系統這些具有創造性與成就感的本職工作上。
兩個概念：本質複雜度（Essential Complexity）和偶然複雜度（Accident Complexity）
- 本質複雜度就是解決一個問題時，無論怎麼做都必須要做的事
- 偶然複雜度是因爲選用的做事方法不當，而導致要多做的事
- 舉例說明：比如你要做一個網站，網站的內容是你無論如何都要寫的，這就是“本質複雜度”。而如果今天你還在用匯編寫一個網站，效率是不可能高起來的，因爲你選錯了工具。這類選錯方法或工具而引發的問題就是“偶然複雜度”
程序員現狀：大部分程序員忙碌解決的問題，都不是程序問題，而是由偶然複雜度導致的問題
一個思考框架、圍繞這個框架的原則
- 原則：以終爲始、任務分解、溝通反饋、自動化
- 你以爲的“終”可能不是終，因爲你只是站在自己的角度；你以爲自己做了任務分解，在我看來，可能還不夠，因爲我希望你能夠做到微操作；你以爲的溝通反饋就是說話聊天，我想告訴你很多技術實踐的存在也是爲了溝通反饋；你以爲自動化就是寫代碼，我會告訴你，有時候不寫代碼而解決問題，可能纔是一個好方案。
不會工作方法沒關係，可怕的是深陷泥潭而不自知
思考框架
由於偶然複雜度造成的差距會有多大呢？
1975 年，弗雷德裏克·布魯克斯（Frederick Brooks）出版了軟件行業的名著《人月神話》，他給出了一個統計結果，優秀程序員的開發效率是普通程序員的 10 倍。40 多年過去了，這個數字得到了行業的普遍認同。
一個思考框架
原文
- Where are we?（我們現在在哪？）
- Where are we going?（我們要到哪兒去？）
- How can we get there?（我們如何到達那裏？）
這三個問題實際上是幫我們確定：
- 現狀
- 目標
- 實現路徑
如果一個人能夠清晰地回答出這三個問題，通常意味着他對要做的事有着清晰的認識
結合具體場景
在實際的工作中，這個思考框架會幫助我更好地瞭解自己的工作。比如，當一個產品經理給我交代一個要開發的功能特性時，我通常會問他這樣一些問題：
- 爲什麼要做這個特性，它會給用戶帶來怎樣的價值？
- 什麼樣的用戶會用到這個特性，他們在什麼場景下使用，他們又會怎樣使用它？
- 達成這個目的是否有其它手段？是不是一定要開發一個系統？
- 這個特性上線之後，怎麼衡量它的有效性？
如果產品經理能夠回答好這些問題，說明他基本上已經把這個工作想得比較清楚了，這個時候，我纔會放心地去了解後續的細節。
我們用思考框架對照一下，爲什麼我會問這些問題。一般來說，一個新特性要開發時，現狀我是知道的。所以，我更關心目標，這裏“爲什麼要做這個特性？”就是在問目標，“給用戶帶來怎樣的價值”是在確定這個目標的有效性。
接下來，我會關注實現路徑，用戶會怎麼用，是否有其他的替代手段，我需要了解產品經理的設計是經過思考的，還是“拍着腦袋”給出的。衡量有效性，則是要保證我的工作不會被浪費。
具體問題怎麼問遵循四項基本原則
以終爲始就是在工作的一開始就確定好自己的目標。我們需要看到的是真正的目標，而不是把別人交代給我們的工作當作目標。你可以看出這個原則是在幫助我們回答思考框架中，Where are we going?（我們要到哪兒去？）這個問題。
任務分解是將大目標拆分成一個一個可行的執行任務，工作分解得越細緻，我們便越能更好地掌控工作，它是幫助我們回答思維框架中，How can we get there?（我們如何到達那裏？）的問題。
如果說前兩個原則是要在動手之前做的分析，那後面兩個原則就是在通往目標的道路上，爲我們保駕護航，因爲在實際工作中，我們少不了與人和機器打交道。
溝通反饋是爲了疏通與其他人交互的渠道。一方面，我們保證信息能夠傳達出去，減少因爲理解偏差造成的工作疏漏；另一方面，也要保證我們能夠準確接收外部信息，以免因爲自我感覺良好，阻礙了進步。
自動化就是將繁瑣的工作通過自動化的方式交給機器執行，這是我們程序員本職工作的一部分，我們擅長的是爲其他人打造自動化的服務，但自己的工作卻應用得不夠，這也是我們工作中最值得優化的部分。
這四個原則互相配合，形成了一個對事情的衡量標準。總體上可以保證我的工作是有效的，在明確目標和完成目標的過程中，都可以儘量減少偶然複雜度。
怎麼把這四個原則用在工作中呢？我們回過頭來看一下前面的場景，產品經理把要做的功能特性擺在我面前。站在以終爲始的角度，我需要了解真正的目標是什麼，所以，我會關心爲什麼要做這個特性。爲了保證目標是有效的，我會關心它給用戶帶來的價值。
有了任務分解的視角，我需要將一個大的目標進行拆解，如果我要達成這個目標，整體解決方案是遠遠不夠的，我需要把任務分解成一個一個小的部分。所以，我會關心一個一個具體的使用場景。
一方面，我會了解到更多的細節，另一方面，當時間緊迫的時候，我會和產品經理來談談究竟優先實現哪個場景。
爲什麼要學會溝通反饋？因爲我需要明確，自己是否真正理解了產品經理提交的需求。所以，我要不斷地問問題，確保自己的理解和產品經理交代的內容一致。
另外，我也需要保證我的產品做出來確實能夠達到目標。所以，我會關心它上線後的衡量手段。因爲我知道，這個行業裏有太多代碼上線後，從來沒有運行過。
自動化的角度很有意思，我們做的方案通常是一個自動化方案，但我們需要了解這個方案沒有自動化之前是怎麼做的。如果不自動化，用戶會怎麼用。所以，我會關心是不是還有其它替換方案，比如，買一個現成的服務。因爲很多需求的提出，只是因爲我們有了一個開發團隊而已。
我們不是一個人孤獨地在工作，而是與其他人在協作，想要做到高效工作，我們就要“擡起頭”來，跳出寫代碼這件事本身。所以，我在開篇詞裏說，程序員解決的問題，大多不是程序問題。
我的個人博客網站是：www.coderyyn.cn
上面會不定期分享有關爬蟲、算法、環境搭建以及有趣的帖子
歡迎大家一起交流學習
轉載請註明