天正高，歌正長

我通常會在文章的末尾向大家介紹我覺得不錯的書，但很少“專門”推薦某一本書。之前的《把名字寫在水上》算是個例外，今天，我打算再破一次例。

前幾個月，偶然遇到了飛機設計師程不時的自傳《天高歌長：我的飛機設計師生涯》。我看完覺得不錯，又推薦給身邊的朋友，不少人都覺得不錯。是以我想，有必要寫篇文章專門談談這本書。

程不時是誰？是我國著名的飛機設計師。“飛機設計師”這個職業可能讓很多人感到陌生，但“不時”這個名字是很容易引起好奇的。

“不時”這個名字是有來由的。程不時出生在民國典型知識分子家庭，父親同濟大學畢業後赴德國深造，母親畢業于湖南第一女子師範學院。取名“不時”，一方面是希望這個名字有特色，獨一無二，另一方面也是希望他做人不追求時髦，踏實沉穩。

名字有意思，他設計飛機更有意思，這些飛機的命運都挺特别：

五十年代他設計過“初教6”教練機，在“全面照搬蘇聯”的年代并不受上司青睐，卻至今被美國飛行愛好者熱愛（有多方證據證明），成了在美國銷量最大的中國産飛機（超過200架），看新聞最近又應需求重新開始生産了；

後來他設計了“強5”強擊機，頗有前瞻性地采用了兩側進氣的方案，設計很超前，裝備部隊卻很晚，服役期也很長，很長時間内“五爺”是我國唯一能遂行對敵攻擊任務的飛機；

1970年，因為毛澤東說“上海可以搞飛機嘛”，上海市緊鑼密鼓開始為研制客機“供總理出國用”，這就是程不時先生參與設計的“運十”，1980年試飛成功之後，86年國務院否決了後續撥款，“運十”項目徹底下馬；

看到這裡，我們可以根據程先生的出身和工作成果想象他的樣子了：除了有很高的科學文化素養，而且心氣不低，心态應當不錯，生活中也很願意動腦筋…… 由此類推，他的自傳當然是會比較好看的。

事實也确實如此。這本自傳包含了很多内容，有興趣的讀者可以找來仔細讀。我之前寫的《文不如表，表不如圖》，就是受這本自傳的啟發。今天，我想再講兩個讓我印象深刻、感慨良多的細節。

程不時上國小的時候，父親要求他每天寫一篇日記。對小朋友來說，這簡直是一種負擔，因為“根本沒有那麼多事情可以寫”。有一天，程不時心血來潮，仿照報紙上“法新社電”、“路透社電”、“美聯社電”新聞的樣子，把自己看到的事情記下來：今天媽媽給小弟洗澡，小弟很調皮，把水都濺到盆子外面了……

寫日記應當是很嚴肅認真的事情，因為寫不出日記，怪模怪樣地仿照新聞來寫，本來不算什麼好事。不料程父見到之後，不但不責怪他，反而專門請了做編輯的朋友來，批評指導程不時的寫作，講解小說和報道的差別，并講解了排版等專門知識……

據程不時先生回憶，這是“第一次聽到寫作方法性的啟蒙，簡直聞所未聞，收獲巨大”。

這個小故事之是以讓我印象深刻，程父的舉動倒是其次，我好奇的是，程不時是怎麼從人家的批評指點獲得巨大收獲的呢？要知道，不是人人都能享受這種機會的。更重要的是，即便有這種機會，也未必能擺正心态面對。

舉例來說，今天很多人都寫微信公衆号，當然也有人會評價其他人的文章。平心而論，有些評價确實有見地，能給人啟發。然而我們平時看到的是，遇到“稱贊”的意見大家往往都能（故作）謙虛一番，可是遇到非“稱贊”的評論意見，相當多的寫作者都不太舒服，第一反應都是辯駁，甚至反唇相譏。即便提出意見的人是行家又怎麼樣？“擠兌行家”的辦法，一搜一大堆。

我再舉個例子：好些年前有個名為“譯言”的網站，聚集了不少翻譯愛好者。很多人純粹出于興趣，做了大量公益性質的翻譯。當時我已經積累了一些翻譯經驗，也樂于與人交流。是以，我也經常浏覽譯言網。

我發現，譯言網确實是譯者交流的好場所。尤其難能可貴的是，每次新出來一篇翻譯，後面都有不少人加油，既消除了譯者的孤獨感，也營造了良好的社群氣氛。

但是我也清楚，翻譯是一門“入門容易做好難”的工作。要做好翻譯，就不能滿足于“語言的使用者”，而應當努力成為“語言的分析者”，其他人的挑刺和建議也是必不可少的。否則，經常容易出現錯譯、漏譯等問題，而且不自知。

本着“分享”的精神，我也會去人家的譯文下認真提提意見，指出翻譯中的錯誤。不過我很快發現，在衆多“辛苦了”、“棒”、“繼續加油”的留言中，我的留言似乎顯得很另類，也很少有回應。即便有回應，通常也是不歡迎的态度。

為什麼會這樣呢？我仔細看看自己的留言，确信是“對事不對人”的。如果能認真看看我的留言，相信譯者的翻譯水準會有很大提升。可是，怎麼就不受歡迎呢？

我想起自己剛學翻譯時候，也是被人挑了很多錯，許多時候還說得并不客氣。為什麼那時候自己就能接受呢？想來想去，和譯言網的譯者們大概有兩點不一樣：第一，那時候給我挑錯的還算知名學者（網際網路早期還有這種風氣）；第二，當時的挑錯是通過電子郵件通訊的，不是在網站上留言，人人都能看到的。

我扪心自問，第一點最重要，因為人家的地位學識比我高很多，是以我“心甘情願”接受人家的挑錯；第二點也有影響，但沒那麼重要。是以最終的結果就是，我的第一反應不是“不高興”，而是願意去接受和了解，哪怕之後不了解、不贊同，也和“不高興”不沾邊。

是以看到程不時小時候的故事，我忽然有了似曾相識的感覺。對小時候的程不時來說，“父親請來的編輯朋友”是成年人，又做這方面的工作，是以天然就有“專業權威”的形象，值得仰視。是以，孩子“預設”專業的成年人說的是對的，第一反應絕對不是排斥，而是聽取。最終，孩子也從中收獲了很多。

實際上，不隻是程不時，許多兒童都能保持這種謙遜的好奇心。但是，這或許不隻是因為孩子的好奇心重，也因為他們預設信任“大人”，自己也天然沒有那麼強的自我保護欲，沒有那麼強的面子意識。

成年之後，我們懂得複雜，不再那麼容易去認定和仰視權威。我們追求自由，關心自己的表達不受束縛和挑戰。我們關心面子，尤其不喜歡在衆人面前遇到不同意見。遇到不同意見，除非對方是我們特别信任的朋友，或者毫無疑問的權威，否則我們的第一反應往往是“我沒有問題”，或者“這不是我的問題”。結果，即便人家說的有道理，哪怕人家說的很客觀，我們也很難聽進去。

寫到這裡，我又想起李笑來老師講過的：很多時候，給學生講課，并不是因為講得好，是以學生覺得老師牛；而是因為學生首先覺得老師很牛，認真對待老師講的内容，繼而覺得“講得好”。即便是好的老師，先能給人“牛”的感覺，後續傳授起知識來也會容易很多。另一方面，隻會扯淡的老師，如果能裝出“牛”的感覺，也有很大機率把學生帶歪。

那麼，整個故事告訴我們什麼道理？我覺得有兩方面：

一方面，如果要向其他人傳遞資訊，傳遞的效果很多時候并不取決于資訊本身的品質，努力制造“其他人願意接受”的局勢，是保證效果的有效工具；另一方面，我們面對不同意見時，“厭惡”和“排斥”也許是第一反應，這也是正常的，但如果我們能克制這種第一反應，認真聽聽意見——無論它來自哪裡，來自什麼人——或許會更有收獲。

《天高歌長》中讓我深刻的第二個故事來自程不時在設計飛機時與其它設計人員的交流：

有根拉杆要穿過的地方出現了一個凸起，設計人員設計了一個很複雜的搖臂系統把力傳導過去。程不時說：“你用一個彎杆就可以了呀。” 那名設計人員将信将疑，重新設計後果然簡潔了很多，功能也沒有任何影響。還有一次，某根油箱管的通路上出現障礙，一開始結構也是搞得特别複雜，程不時說：“你用一根彎管就可以了呀，液面高度不會受影響的。” 設計人員一開始也是将信将疑，後來發現真的可以。

彎杆、彎管，看起來當然不美，甚至很“醜”。竟然直接采用這樣“簡單粗暴”的辦法，是因為程不時的專業素養不夠好嗎？應該不是，程先生49年前就考上了清華大學，大學就是學的航空相關專業，受過嚴格規範的訓練。那麼程先生為什麼要采用這樣“醜陋”的解決方式？我覺得，恰恰是受過了嚴格規範的訓練，又不被簡單直接的思維方式和判定标準限制，才提得出這樣的辦法。因為他聚焦的是“根據不同的實際問題選擇手段”，而不是“用不變的手段去解決各種實際問題”。

如果這麼說很麻煩，不妨再說說很多人熟悉的“生産線小工用電風扇檢測空肥皂盒”的故事，覺得很好笑。最開始聽到這故事的時候，我也覺得很好笑，能用電風扇解決的問題，怎麼會“蠢”到用高精尖的機器臂去解決？但是，發現我們自己也會不自覺這樣做事時，就一點也不好笑了。

許多年前，我接手過一個賬号遷移的任務，把遺留的老賬号整體遷移到另一個系統裡。因為遺留系統“上了年紀”，設計時也沒有考慮過未來的遷移，是以無論如何，總會有一部分使用者不能“無縫”遷移，總沒有完美的方案。就這樣，我們讨論來讨論區，兩個禮拜都沒有設計完成。

有一天老大問起這件事情，知道還沒有設計完成，他感到很詫異：怎麼會拖這麼久？于是我們去解釋來問題的來龍去脈。老大說：那你們去查查，影響使用者數最小的方案裡，受影響的使用者都是什麼人，通路頻率是怎麼樣的？

結果查出來，大概有幾百名使用者受到影響，其中大部分都是隻注冊過，很少登入，基本沒有留下任何資料的使用者。真正受影響的活躍使用者隻有個位數。于是老大拍闆說：這部分使用者，不活躍的不考慮了。真正受影響的活躍使用者，給他們逐個溝通，出人工解決方案。

我們設計就耗費了兩個禮拜還沒決定的問題，這麼拍闆之後，一個禮拜就完成上線了。辦法讓我無可厚非，時間讓我目瞪口呆，經曆讓我印象深刻——原來，還可以這麼辦。

等到我的後一份工作，又遇到了這種情況。當時我們開發的是一款閱讀平台，聯系作者和讀者。如果作者更新了，必須盡快通知讀者。但是，誰也不知道作者什麼時候更新，畢竟寫作是随性的事情。是以系統設計了複雜的公式，加入各種變量，效果都不好。

最後真正提升閱讀效果的卻是反其道而行之，簡單粗暴的竅門：看看目前有哪些讀者線上（當時還沒有移動網際網路，是以也沒有“離線推送”這一說），這些讀者對應哪些作者，高頻度掃描這些作者的狀态。其它作者則保持以前的模型檢查更新。這樣既減少了系統的負擔，又保證了使用者的體驗。不過，它确實和高大上的模型和算法不沾邊。

我逐漸發現，這樣“看不上簡單解決方案”的現象其實挺普遍，在IT行業就更普遍。這或許和IT的工作性質有關：大家習慣的都是“理想化”的世界，這個世界裡有各種直覺的公式、邏輯、規律、原則。大家習慣的世界裡，線條必須是直的，圓圈必須是正的，顔色必須是純的…… 

無數的故事都在描繪這種場景：再雜亂的場合，一個指令敲下去、一段代碼跑起來，世界就清淨了。同時，也有很多程式員大方承認：自己喜歡這份工作，就是因為喜歡自己的操控權，享受那種駕馭感和秩序感。

然而現實世裡，許多事物就是沒有辦法變成四四方方、橫平豎直的樣子；許多問題就是需要去權衡取舍，沒有完美辦法；許多方案就是要針對特殊情況打一些更新檔，不能幾個簡單原則通吃四方。雖然我們身處IT行業，所面對的世界通常是嚴格按照規則來運轉的，仍然需要承認現實世界是麻煩的、複雜的，需要适時放棄對“一次性的”、“完美的”的執着。

IT行業确實有不少問題，比如注冊登入、權限管理，确實有很現成的解決方案。這些方案很完備，也很美，實施之後确實非常有成就感。但是有時候也會限制大家的思維。明明很長時間裡隻有少數“自己人”用的系統，也要搭一套完備的賬号和權限系統。明明用“簡單粗暴”的手段可以簡單迅速解決問題的，非要裝一整套工具和架構來解決。結果，技術人員的成就感倒是有了，真正的問題卻沒有及時解決。

這個問題其實是普遍存在的。在部落格誕生之前，矽谷天才計算機科學家Rick就想做個服務讓大家能在網上釋出文章。他為自己的想法感到無比激動，也看到了後面的商機。他每天為此投入15小時，并且迅速開發出原型。

然後，他發現程式設計語言用起來不太順手，于是希望開發一種能讓自己新的語言，提升軟體的效率。于是他又投入了整整四年，越陷越深。在這四年裡，其他人紛紛開發自己的部落格平台，收入頗豐。然而Rick，仍然在執着地打造他自己的程式設計語言……

我也參加了不少設計讨論會，發現各種方案争來争去出不來結果，往往都是集中于抽象的價值：是“對”還是“錯”，是“好”還是“不好”，是“美”還是“不美”、是“優雅”還是“不優雅”。争論到後來大家還可以引經據典，搬出各路神仙來助陣，于是分歧越來越大，結論越來越難達成。

換個角度來看，這些争論往往都“站着”是從定性的角度，而不是坐下來定量着手：目前問題的核心到底是什麼？它的影響範圍如何衡量？衡量的名額是什麼？面對這些名額，我們可選的方案是什麼，各有哪些成本，是否能夠接受？……