10x程式設計師工作法筆記

我在某平台上學習10x程式設計師工作法，特此記錄下我結合工作中實際情況對10x程式設計師工作法的理解與總結

作為程式設計師，我們將其看作乙個值得全情投入的職業，希望能夠把精力放在設計演算法、改進設計、優化系統這些具有創造性與成就感的本職工作上。

由於偶然複雜度造成的差距會有多大呢？

1975 年，弗雷德里克·布魯克斯（frederick brooks）出版了軟體行業的名著《人月神話》，他給出了乙個統計結果，優秀程式設計師的開發效率是普通程式設計師的 10 倍。40 多年過去了，這個數字得到了行業的普遍認同。

這三個問題實際上是幫我們確定：

如果乙個人能夠清晰地回答出這三個問題，通常意味著他對要做的事有著清晰的認識在實際的工作中，這個思考框架會幫助我更好地了解自己的工作。比如，當乙個產品經理給我交代乙個要開發的功能特性時，我通常會問他這樣一些問題：

如果產品經理能夠回答好這些問題，說明他基本上已經把這個工作想得比較清楚了，這個時候，我才會放心地去了解後續的細節。

我們用思考框架對照一下，為什麼我會問這些問題。一般來說，乙個新特性要開發時，現狀我是知道的。所以，我更關心目標，這裡「為什麼要做這個特性？」就是在問目標，「給使用者帶來怎樣的價值」是在確定這個目標的有效性。

接下來，我會關注實現路徑，使用者會怎麼用，是否有其他的替代手段，我需要了解產品經理的設計是經過思考的，還是「拍著腦袋」給出的。衡量有效性，則是要保證我的工作不會被浪費。

具體問題怎麼問遵循四項基本原則

以終為始就是在工作的一開始就確定好自己的目標。我們需要看到的是真正的目標，而不是把別人交代給我們的工作當作目標。你可以看出這個原則是在幫助我們回答思考框架中，where are we going?（我們要到哪兒去？）這個問題。

任務分解是將大目標拆分成乙個乙個可行的執行任務，工作分解得越細緻，我們便越能更好地掌控工作，它是幫助我們回答思維框架中，how can we get there?（我們如何到達那裡？）的問題。

如果說前兩個原則是要在動手之前做的分析，那後面兩個原則就是在通往目標的道路上，為我們保駕護航，因為在實際工作中，我們少不了與人和機器打交道。

溝通反饋是為了疏通與其他人互動的渠道。一方面，我們保證資訊能夠傳達出去，減少因為理解偏差造成的工作疏漏；另一方面，也要保證我們能夠準確接收外部資訊，以免因為自我感覺良好，阻礙了進步。

自動化就是將繁瑣的工作通過自動化的方式交給機器執行，這是我們程式設計師本職工作的一部分，我們擅長的是為其他人打造自動化的服務，但自己的工作卻應用得不夠，這也是我們工作中最值得優化的部分。

這四個原則互相配合，形成了乙個對事情的衡量標準。總體上可以保證我的工作是有效的，在明確目標和完成目標的過程中，都可以儘量減少偶然複雜度。

怎麼把這四個原則用在工作中呢？我們回過頭來看一下前面的場景，產品經理把要做的功能特性擺在我面前。站在以終為始的角度，我需要了解真正的目標是什麼，所以，我會關心為什麼要做這個特性。為了保證目標是有效的，我會關心它給使用者帶來的價值。

有了任務分解的視角，我需要將乙個大的目標進行拆解，如果我要達成這個目標，整體解決方案是遠遠不夠的，我需要把任務分解成乙個乙個小的部分。所以，我會關心乙個乙個具體的使用場景。

一方面，我會了解到更多的細節，另一方面，當時間緊迫的時候，我會和產品經理來談談究竟優先實現哪個場景。

為什麼要學會溝通反饋？因為我需要明確，自己是否真正理解了產品經理提交的需求。所以，我要不斷地問問題，確保自己的理解和產品經理交代的內容一致。

另外，我也需要保證我的產品做出來確實能夠達到目標。所以，我會關心它上線後的衡量手段。因為我知道，這個行業裡有太多**上線後，從來沒有執行過。

自動化的角度很有意思，我們做的方案通常是乙個自動化方案，但我們需要了解這個方案沒有自動化之前是怎麼做的。如果不自動化，使用者會怎麼用。所以，我會關心是不是還有其它替換方案，比如，買乙個現成的服務。因為很多需求的提出，只是因為我們有了乙個開發團隊而已。

我們不是乙個人孤獨地在工作，而是與其他人在協作，想要做到高效工作，我們就要「抬起頭」來，跳出寫**這件事本身。所以，我在開篇詞裡說，程式設計師解決的問題，大多不是程式問題。