去年底看到陳皓（酷殼博主）寫了篇很好的文章《技術人員的發展之路》，裡面提及職業發展的一定階段，也許你會碰上一些複雜的人和事，這種情況下他寫道：
這個時候再也不是 talk is cheap, show me the code! 而是，code is cheap, talk is the matter!
這裡的 talk 其實就是溝通，近年來發現溝通越發成為一件重要的事。在近期的工作中也會觀察到一些溝通問題，比如跨團隊開會溝通時發生的一些分歧與爭論。作為程式設計師的我感覺溝通一直是一個痛點，所以近年來一直在思考關於溝通的問題，下面就寫寫我的觀察與思考吧。
木訥與沉默
這兩個名詞似乎已變成了程式設計師的標籤，它們形象地體現了程式設計師在溝通中的表現。在程式設計師的世界裡，溝通可能包括：與產品經理溝通需求、與同行交流技術、與外行交談，還有與同事分享工作與生活的趣聞等。
有些程式設計師在分享趣聞與談需求或技術時的表現大相徑庭，剛才還是一個開朗的小夥突然就變得沉默不語了。沉默有時是不想說，特別在溝通需求時，程式設計師心裡想著：與其扯那麼多，哥程式碼都寫完了。不就是一個小功能嗎，默默無言，笑而不語的就接下了，想著趕快結束去寫程式碼了。
程式設計師寫出的程式碼本應該是公司的資產，但現實是程式碼這東西是同時帶有資產和負債雙屬性的。Linus 寫的 Linux 或者 @antirez 貢獻的 Redis 裡面包含的程式碼是極好的資產，但大部分我們溝通不充分的需求，最後基於此寫出來的程式碼都是負債大於資產。最後，往往是出來混都是要還的，不是自己還就是別人來還。
程式設計師可能會爭辯道，與人溝通本來就不是我們所擅長的，我們並不是因為熱愛跟別人聊天才做軟體開發這一行的。這個言論很有迷惑性，我早年一度都是這麼認為的。當年畢業去找工作，外企如日中天，去了當時心中的很牛的 IBM 面試。面試過程中大部分的交談過程我都記不清了，就一個問題至今很清晰。面試經理問我：你是喜歡多些跟人打交道呢，還是跟電腦打交道？當時的我毫不猶豫的回答喜歡跟電腦打交道，喜歡程式設計寫程式碼，而且自覺我也不擅長和人打交道。
然後，我就被淘汰了。後來我才明白了，其實當時的這類外企掛著招軟體工程師的名義，實際需要的更多是具有技術背景和理解的售前技術支援，因為在國內它們基本就沒有一個真正的研發中心。如今我認為，即便你僅僅只喜歡寫程式碼，那麼和人的溝通能力依然是你跨不過去的瓶頸。寫程式碼本身就是一種溝通，一種書面溝通。
程式寫出來是給人看的，附帶能在機器上執行。
–《計算機程式的結構與解釋》
溝通從來都是個問題，書面溝通同樣困難。
爭論與無奈
程式設計師產生爭論的地方多半都在和同行的溝通中，想必很多人都和同行有過關於技術方案的爭論。我自己就曾在過去多年的工作中和同事有過技術方案之爭，得到的教訓可以建議給技術經理（主管）們：不要讓兩個都覺得自己很牛的程式設計師去同時設計一個技術方案。不巧，你已經這麼幹了並得到了兩個不同的方案，那麼記住，就別再犯下一個錯：讓他們拿各自的方案去 PK。
既然分歧已經產生了，為了避免無謂的爭論，該怎麼解決呢？
以理服人
首先，把握一個度，對事不對人，切勿意氣用事。有些技術人之間的分歧點是非常詭異的，這可能和技術人自身的潔癖、口味和偏好有關。比如：大小寫啦、命名規則啦、大括號要不要獨立一行啦、駝峰還是下劃線啦、Tab 還是空格啦，這些都能產生分歧。一旦處女座心態爆發，很可能一發不可收拾。
如果你因為“該怎麼做某事或做某事的一些形式問題”與他人產生分歧，那麼在很多情況下，你最好先確定分歧點是否值得你去拼命維護。這時，你需要判斷一個技術的「理」在什麼地方，這個「理」是你值得拼命堅守的底線不，用這個「理」能否說服對方嗎？
我所理解的技術的「理」包括：先進性、可驗證性、適配性（和團隊）、時效性、成本和收益。另外一些不合適的「理」包括：風格、口味、統一、政治。
不過有時候，有理也不代表就能搞定分歧，達成一致。林子大了，不講理的人也是有的，那麼下一步。
以德服人
分歧進入用「理」都無法搞定時，那就是應了那句古詞：“剪不斷，理還亂。”。這時繼續理下去，不過都是互相耍混了。
「理」是一個客觀需要雙方去認可的存在，越理越亂說明雙方至少沒有這種客觀一致性的基礎，那就找一個主觀的人來做裁決吧。
德，謂之德高望重，是否有一個雙方都認可的人來做裁決，這個人通常就是所謂經驗豐富的老司機了，比如架構師之類的。這類主觀裁決也不一定能讓雙方都滿意，有時實力相當的技術人也容易產生類似文人相輕的狀況。不過看在老司機的德面上，也能勉強達成一致。
老司機裁決最好站在他所認同的「理」的這個客觀存在上，這是最好的，不過這也取決於老司機的工作素養和價值觀了。
以力服人
最差的狀況就會走到這一步，特別在跨大部門的溝通中。技術方案無法達成一致，也沒有一個跨兩個部門的有德之人可以轉圜化解，就會升級到這個地步。
最後就是靠粗暴的權力來裁決，看雙方部門老大或老大的老大，看誰更有力或給力。一般來說非關鍵利益之爭實在沒有必要走到這一步了。
認識與改變
做出改變的第一步是要能認識到，否則改變不可能發生。程式設計師會認識到溝通很重要，有時會比寫程式碼更重要嗎？程式設計師著名網站之一 StackOverflow 的兩位創始人 Jeff Atwood 和 Joel Spolsky 都對此有正面的認識和見解。
Jeff 說：
成為一名傑出的程式設計師其實跟寫程式碼沒有太大關係。
做程式設計師確實需要一些技術能力，當然還要有堅韌不拔的精神。
但除此之外，更重要的還是要有良好的溝通技巧。
Jole 的觀點：
勉強過得去的程式設計師跟傑出程式設計師的不同之處，不在於他們掌握了多少種程式語言，也不在於他們誰更擅長 Python 或 Java。
真正關鍵的是，他們能不能把他們的想法表達清楚，傑出的程式設計師通過說服別人來達成協作。
通過清晰的註釋和技術文件，他們讓其他程式設計師能夠讀懂他們的程式碼，這也意味著其他程式設計師能夠重用他們的程式碼，而不必重新寫過。
要不然，他們程式碼的價值就大打折扣了。
按照程式設計師解決技術問題的習慣，就是對大問題作拆解，我們也對溝通作下拆解，它包括三個方面：
- 內容
- 方式
- 風格
從內容看，即使你想溝通的本質是同一樣東西或事情，但你需要針對不同的人準備不同的內容。比如程式設計師和內行與外行談同一個技術方案，內容就是不同的。這裡需要發揮同理性和換位思考的能力。Paul Graham 曾在他的書《黑客與畫家》中寫到：
判斷一個程式設計師是否具備“換位思考”的能力有一個好方法，那就是看他怎樣向沒有技術背景的人解釋技術問題。
換位思考本質上就是溝通技巧中的一種。
從方式看，溝通其實不侷限於面對面的談話，面對面交談是一種形式，書面寫作又是另外一種形式，連寫程式碼本身都是在和未來的自己或某個你尚未謀面的程式設計師溝通。對於程式設計師確實有很多都不擅長面對面的溝通形式。
面對面溝通的場景是很複雜的，因為這種溝通中交流傳遞的載體不僅僅是言語本身。你的眼神、姿態、行為、語氣、語調高低，甚至一種很虛幻的所謂氣場，都在傳遞著各種不同的資訊。而大部分人都不具備這種同時控制好這麼多傳遞渠道的能力，我們經常通俗的說是缺乏控場能力，這裡面隱含著對你其他能力的要求，比如：機變、思維的活躍度與變化等。
從風格看，交談風格和寫作風格可以是完全不同甚至對立的。比如：「小道訊息」的作者 Fenng（馮大輝）的文字風格很多時候給人的感覺是簡短、尖銳和犀利的，但據說（來自知乎評論）其私下的面談風格完全與之不同。
因而，溝通之難在於清晰的傳遞內容和觀點。當你要向其他人詳細解釋某樣東西的時候，你會驚訝地發現你有多無知，於是，你不得不開始一個全新的探索過程。這一點可以從兩個方面來體會：
- 你只需要嘗試寫點你自認為已經熟悉掌握的技術，並交給讀者去閱讀與評價。
- 如果你的公司晉升採用一種述職答辯的方式（現在很多網際網路公司採用），你就會體會到這一點。
我每次寫完一篇技術文章，都會發現一些漏洞或者 bug，主要出現在我總覺得我想表達的東西沒有足夠清晰或是有歧義，或漏了一些。但文字不像程式碼，你搞錯了一些東西，漏了幾個字元，編譯器或執行環境會給你扔出幾個警告或錯誤，或者乾脆就不讓你執行。所以也很難像寫程式碼一樣去反覆重構和優化文字。
…
江山易改，本性難易，有時候我們做不到就在於這一點。
如何更好的溝通對我也是一個很難的挑戰。不過若能通過本文，讓你瞭解到這種處境，即使還無法做出任何改變，但僅僅是瞭解了這個事實，也可能會讓你感受好些。