我正在一點一點的從一個工程師轉(zhuǎn)型為管理者。別弄錯了，雖然我在轉(zhuǎn)管理，但我仍然在每天寫代碼。不過我發(fā)現(xiàn)自己在會議和電話中會花越來越多的時間去分析討論，試著去組織團(tuán)隊，并且為全局部署而不是具體戰(zhàn)術(shù)而煩惱。

當(dāng)然這不是一件壞事。高層次的決策往往比單個的類和函數(shù)的細(xì)節(jié)更有影響。讓一個團(tuán)隊更有效率，比僅僅讓自己更有生產(chǎn)力有更高的杠桿作用。但我想我已經(jīng)從我多年來的編程中吸取到了一些經(jīng)驗。我希望大部分經(jīng)驗可以應(yīng)用于管理方面。

1、沒有規(guī)定（rules），只有公案（koans）

譯注：公案（Koan）有五種重要的涵義： 作悟禪的工具； 作考驗的方法； 作權(quán)威的法范； 作印證的符信； 作究竟的指點。）

舉個例子：DRY，意思是「不要重復(fù)你自己」。作為軟件的基本規(guī)則這很好理解，因為很多話可以證明：“我做 X 是因為它沒有重復(fù)。”這說得通，不是嗎？如果你有兩個或者兩個以上部分的代碼在做相同的事情，說明你正在浪費。而且如果當(dāng)你需要改變它們其中一個的時候，你可能也需要改變其他的，并且你很可能會忘記這么做。當(dāng)它們不同步時，你會得到一個怪異的 bug。因此很顯然你不能重復(fù)你自己。

然而，在使用了幾年之后，人們開始懷疑它的普遍適用性。假如你的兩個方法中包含相同的代碼塊，所以你將其拿出來形成一個單獨的函數(shù)。通常那些方法會開始朝不同的方向發(fā)展…接著你發(fā)現(xiàn)自己要在函數(shù)中加入更多的參數(shù)，很可能為結(jié)果立了更多 flags……然后下一個接手的程序員會因為分離出來的函數(shù)以及它所帶的特定的參數(shù)和結(jié)果，而出現(xiàn)認(rèn)知負(fù)載。你會意識到如果當(dāng)初允許自己重復(fù)，并讓兩塊代碼自然的發(fā)展為不同的個體，你生成的代碼將會更簡單直觀。

這意味著 DRY 不好嗎？當(dāng)然不是！通常在合適的環(huán)境下使用 DRY 是正確的…好吧，也許。我個人的經(jīng)驗是：“重復(fù)一次是可以的，超過一次就不太好了…當(dāng)然這取決于所處的環(huán)境。”因為所有事都取決于環(huán)境。DRY 的目的并不是為了 DRY。如果你迷信于此，小孩兒，那你還有太多要學(xué)。DRY 的目的為了讓你了解 DRY。那當(dāng)然不是規(guī)定，僅僅是公案。

（讓我重申一遍：我在討論的是軟件。在我的經(jīng)驗中，硬件規(guī)定的確更傾向于是我們所理解中的規(guī)定。這就是我為什么要從電氣工程轉(zhuǎn)到軟件的原因）

細(xì)想我最喜歡的兩個計算機(jī)科學(xué)“定律”。第一：“計算機(jī)科學(xué)中沒有一個問題是不能通過添加另一層抽象來解決的！”這句話完全正確嗎？當(dāng)然不。這在現(xiàn)象學(xué)上是正確的嗎？實際上，的確是。這是否意味著抽象是解決任何問題的正確途徑？不，不是。它是一個公案，可以啟發(fā)思想。

還有我歷來最喜歡的：“第一優(yōu)化定律：不要這樣做。第二優(yōu)化定律（對專家而言）：不要又這樣做。”這顯然是一個公案，卻稱自己為法規(guī)。是時候讓你的代碼運行的更快嗎？不。是時候讓你的代碼運行的更快嗎？還不是。什么意思？意思是要考慮到時間，復(fù)雜性，認(rèn)知負(fù)載，具體結(jié)果，生活意義，人類存在的意義。并且三思而后行，小孩兒。但不要花太長時間，我們還有工作要做。

2、要想得到他人的信任，先信任他人

這不僅僅針對于管理者。雖然它對管理者尤其重要。信任是你真正擁有的唯一價值。如果你的公正、判斷、理解、誠實不被信任。接下來你組織的成員將把你視為禍害并繞著你走。然而，如果你是個有能力但不被信賴的開發(fā)者，你可能還有一些價值。雖然你在每個決定上做的努力都會被大大消減。

不過更重要的一點是：一個團(tuán)隊的成員需要互相信任。當(dāng) Natascia 說：“我來解決那個問題單（ticket）”，你必須相信她會去做。當(dāng)你說：“Peter 能在截止時間前完成的。”，你必須相信那會實現(xiàn)。當(dāng)某人說，“我有一個瘋狂的點子”，他們必須信任他們會被尊重和認(rèn)真對待，盡管那點子的確很瘋狂。

你是如何建立和得到信任的？答案很簡單：你去信任他人。你相信那個說他可以學(xué)會這個新庫并且在周一前會整合完的人。你相信那個說他需要提前離開，因為家里有事而會錯過明天工作的人。你相信那些想在截止日期前一個月休假的人，因為他們覺得自己已經(jīng)開始筋疲力盡了。你相信說想要解決難題的初級程序員。

但你不總是正確的。有些時候人在工作上存了壞心。你需要揭露這些人的真面目，讓他們盡早離開。有時候你要信任那些真心想成功的人，雖然他們會失敗。但違反常識的是，長遠(yuǎn)來看這通常是個勝利。因為那些人會記住你的信任，他們會盡一切努力來報答你。

3、簡單比優(yōu)雅重要的多

我也喜歡緊湊優(yōu)雅的代碼。我喜歡靈活的框架，有如此多抽象層次隨時待命，無論拋出什么改變的需求都能解決。我喜歡使用位向量、位位移、略微復(fù)雜的數(shù)據(jù)結(jié)構(gòu)和不太流行且古怪的小語言特性，但在特定環(huán)境下十分實用。

然而你并不只是為了你自己寫代碼。即使它只是個“原型”。（我已經(jīng)記不清我有多少“原型”在多次對層操作和潤色的過程中出現(xiàn)問題。）而且你不僅僅是為了解決當(dāng)前的問題編寫它。你正在為了下一個接手的開發(fā)者可以使用它來解決下一個問題而編寫。把你寫到那五行代碼擴(kuò)充為十行可以增強(qiáng)其可讀性，你知道嗎，也許擴(kuò)展為十五行效果會更好。

你可以提前嘗試并用靈活且充滿抽象的框架解決它們。但是也許預(yù)言不是你的強(qiáng)項，也許你關(guān)于下一個問題的概念的想法完全是錯誤的。也許僅僅編寫足夠簡單的代碼才是最佳選擇。有一個命名約定和一個編碼風(fēng)格，讓它讀起來像英語一樣。也許不是添加一個類，而是下一個開發(fā)者在試圖跟隨你的控制流程時必須保持另一個文件的開放。你應(yīng)該用愚蠢的方式，不雅的方式，簡單的方式。

4、動力比大多數(shù)事都重要

我們都曾見過這種情況。一周里每個人都在檢查代碼，構(gòu)建顯而易見的雛形，每天不斷增加特性，測試覆蓋率越來越高。疏忽也隨著生產(chǎn)的想法和解決方案而出現(xiàn)。不知怎么的下一周所有事都變得緩慢起來。關(guān)于 A 的決定，會影響到 B、C和 D。當(dāng)人們可以運行D、E 和 F 時，它們不是邏輯序列發(fā)展上的一部分。于是需要做更多的假設(shè)，認(rèn)知負(fù)載加重，你不得不模擬出一堆東西來寫出非模仿代碼。一些人需要做這個決定。

或許不是決定會癱瘓，是你上周所做的一切都在錯誤的基礎(chǔ)上，是一個“地震多發(fā)區(qū)”的技術(shù)負(fù)債。你需要停止所有事返回并重構(gòu)它。而且你必須馬上開始，因為等的時間越長，事情會變得越糟糕。沒人想看到這種事發(fā)生 。但他們寧愿現(xiàn)在面對也比下個月知道的好。讓暴風(fēng)雨來的更猛烈些吧。

也許上周每個人都拼勁全力，現(xiàn)在實在撐不住了。你知道該怎樣嗎？得讓他們休息一下，每個人，休息一整天。我保證，這會給你接下來的“長跑”節(jié)省時間。

I我們很難定義、衡量以及說明動力。但它在軟件開發(fā)中是真實存在的東西。而且它的缺失會成為造成首要影響，導(dǎo)致我們需要去解決很多根本問題。別忽略它，也別期望或假裝它會神奇地回來。察覺警報并迅速采取行動。

5、與和你互補(bǔ)而不是像你一樣的人一起工作

每當(dāng)我看到人們根據(jù)“文化契合度”來找人的時候，我就會拼命翻白眼。你知道大多單一栽培會發(fā)生什么嗎？他們遭遇了他們不知如何解決的病原體，然后嗝屁死翹翹了。

你不會希望你的所有開發(fā)者、設(shè)計者、 QA人員、產(chǎn)品人員、銷售人員和執(zhí)行官是彼此的克隆人。你肯定不想。每個人都有自己的長處和短處、優(yōu)點和缺點。你想要雇傭的是他們的長處，讓其他人的長處彌補(bǔ)他們的短處。

比如說我，寫代碼非常快，擅于溝通，讀寫文章都奇快。我在任何時候都能熟悉很多編程語言和框架。我理解東西透徹且迅速，有豐富的經(jīng)驗。然而我還是一個在特定領(lǐng)域、框架和語言缺乏深刻專研、精通掌握的全才。我是一個真正從別人身上獲益的建筑師，跟蹤所有需要，在骨骼構(gòu)建好之后添加肉體和潤色。我還是個 UX 盲（等一下，你說那些還沒對齊？），這一直被當(dāng)作同事之間的玩笑。

像我這樣的人非常難找到也是及其被需要的。但一個由我和九個像我一樣的克隆人組成的公司是從一開始就注定要失敗的。唔，我們會把很多事情做好，但只需要一個集中的盲點，一個災(zāi)難性的空隙就足以毀滅公司。大多數(shù)人承認(rèn)有些事情他們做不好，另一些人可能需要照應(yīng)。這些人往往是尋找“文化契合度”的人，并試圖雇傭和他們一樣的人。真令人哭笑不得。

6、任何決定都比沒決定強(qiáng)

別猶豫，當(dāng)你拿不準(zhǔn)主意時，去做就好了。當(dāng)然，這可能不適用在生產(chǎn)代碼的時候。但它可以應(yīng)用于除此之外在軟件開發(fā)里的任何方面。我們在歷史上發(fā)展最快的行業(yè)里工作。我們生活在以指數(shù)形式發(fā)展的世界里。時間不等人，別浪費它。

這與低級決策的高級討論一樣真實。在高水平的討論里，比如“我們應(yīng)該實現(xiàn)特性 A 還會說 B？我們要用哪種方式實現(xiàn)呢，X 還是 Y？“，常常會產(chǎn)生這樣的對話，”讓我們先跳過這個…下周再對它進(jìn)行討論…“，或者更陰險的，”讓我們先研究一下其他人做了什么再來討論一次。“這樣的問題極少情況下會有正確答案。大多時候，像這么說才是正確的，”我會在今天之前決定嘗試哪一個，這樣我們就可以明天開始行動了。

甚至 A 選項基本上是錯誤選擇，開始進(jìn)行 A 大概也比啥都不做強(qiáng)。這和直覺是相悖的，但它通常也是正確的。以實際上手的方式去理解 A 的本質(zhì)是一個更好的辦法，這個道理始終是正確的。這樣的理解可能會引導(dǎo)你做出更好的決定。

對于低級決策，那就更應(yīng)該如此了。“規(guī)范沒有說明我們應(yīng)該如何處理錯誤條件 X，或者錯誤信息應(yīng)該是什么。”（規(guī)范似乎是為一個有抱負(fù)的烏托邦寫的，在這種烏托邦中，錯誤條件和獨角獸一樣罕見。）“我知道，我只是想插一句，回去問問他們在這種情況下想做什么！”

這非常誘人。如果你這么做，沒人能指責(zé)你哪里做錯了。但這么做是錯誤的。寧愿繼續(xù)自己做決定，盡管有些魯莽，也不要什么都不做等著問別人。讓它們在你做已經(jīng)寫好的程序和你學(xué)到的教訓(xùn)里迭代，雖然你知道這并不完美，也好過從頭開始錯誤認(rèn)知。它們和項目將會變得更好。快速嘗試，快速改變方向。

7、保持謙虛，但要自信

你不需要所有的答案。甚至是我也不得不勉強(qiáng)承認(rèn)我不會有全部的答案。可惡，我甚至連它們的大多數(shù)也沒有，不過我有自信，只要給我足夠的時間和精力，我能弄清楚大部分。并且你也可以。

我們無法都成為 Jeff Dean（谷歌大牛）、中本聰（比特幣創(chuàng)始人） 或是 Margaret Hamilton（登月計劃中的女程序員）。我們在一個充斥著真正的天才和自稱天才的地方工作。沒人知道所有的事情，每個人都敏銳地意識到他們所不知道的一切。幸運的是，大多數(shù)情況下，我們不是科學(xué)家。我們的工作不是去尋找新突破。我們的工作是實踐他人的發(fā)現(xiàn)，使東西運轉(zhuǎn)，希望服務(wù)于人們真正想要的東西。也許你永遠(yuǎn)不會發(fā)明任何東西，像是布隆過濾器或默克爾樹。不過大多與你共事的人們也不會。而且這不是重點，重點是使用布隆過濾器和默克爾樹，亦或是在它們之上建個抽象層，來實際的完成它們。

所以假設(shè)你懂的會比在座的人都多是錯誤的，就算你覺得他們違背直覺的想法很瘋狂，他們的語言選擇很糟糕。假設(shè)人家比你懂的多也是錯誤的，即使真是那樣，也沒關(guān)系。世界上多的是聰明人因為一些不可思議的原因什么實際東西也沒做出來。（開個廉價的玩笑╮（╯▽╰）╭：這就是為什么我們有學(xué)術(shù)界的原因。）

如果你真的做出了一些東西，在面對那些令人眼花繚亂的理論知識，或是和你相似甚至比你做的更糟糕的人時大可不必謙虛。在一天結(jié)束之時，正是那些在戰(zhàn)壕中的開發(fā)者——構(gòu)建、測試和開發(fā)了代碼的人，真正做了事情。話說那些發(fā)現(xiàn)自己遠(yuǎn)離戰(zhàn)壕的人，那些沒有和你一起并肩作戰(zhàn)的逃兵，你有權(quán)利鄙視他們。并且向你的伙伴致敬，而不是上司。