去年底看到陳皓（酷殼博主）寫了篇很好的文章《技術(shù)人員的發(fā)展之路》，里面提及職業(yè)發(fā)展的一定階段，也許你會碰上一些復雜的人和事，這種情況下他寫道：
這個時候再也不是 talk is cheap, show me the code! 而是，code is cheap, talk is the matter!
這里的 talk 其實就是溝通，近年來發(fā)現(xiàn)溝通越發(fā)成為一件重要的事。在近期的工作中也會觀察到一些溝通問題，比如跨團隊開會溝通時發(fā)生的一些分歧與爭論。作為程序員的我感覺溝通一直是一個痛點，所以近年來一直在思考關(guān)于溝通的問題，下面就寫寫我的觀察與思考吧。
木訥與沉默
這兩個名詞似乎已變成了程序員的標簽，它們形象地體現(xiàn)了程序員在溝通中的表現(xiàn)。在程序員的世界里，溝通可能包括：與產(chǎn)品經(jīng)理溝通需求、與同行交流技術(shù)、與外行交談，還有與同事分享工作與生活的趣聞等。
有些程序員在分享趣聞與談需求或技術(shù)時的表現(xiàn)大相徑庭，剛才還是一個開朗的小伙突然就變得沉默不語了。沉默有時是不想說，特別在溝通需求時，程序員心里想著：與其扯那么多，哥代碼都寫完了。不就是一個小功能嗎，默默無言，笑而不語的就接下了，想著趕快結(jié)束去寫代碼了。
程序員寫出的代碼本應該是公司的資產(chǎn)，但現(xiàn)實是代碼這東西是同時帶有資產(chǎn)和負債雙屬性的。Linus 寫的 Linux 或者 @antirez 貢獻的 Redis 里面包含的代碼是極好的資產(chǎn)，但大部分我們溝通不充分的需求，最后基于此寫出來的代碼都是負債大于資產(chǎn)。最后，往往是出來混都是要還的，不是自己還就是別人來還。
程序員可能會爭辯道，與人溝通本來就不是我們所擅長的，我們并不是因為熱愛跟別人聊天才做軟件開發(fā)這一行的。這個言論很有迷惑性，我早年一度都是這么認為的。當年畢業(yè)去找工作，外企如日中天，去了當時心中的很牛的 IBM 面試。面試過程中大部分的交談過程我都記不清了，就一個問題至今很清晰。面試經(jīng)理問我：你是喜歡多些跟人打交道呢，還是跟電腦打交道？當時的我毫不猶豫的回答喜歡跟電腦打交道，喜歡編程寫代碼，而且自覺我也不擅長和人打交道。
然后，我就被淘汰了。后來我才明白了，其實當時的這類外企掛著招軟件工程師的名義，實際需要的更多是具有技術(shù)背景和理解的售前技術(shù)支持，因為在國內(nèi)它們基本就沒有一個真正的研發(fā)中心。如今我認為，即便你僅僅只喜歡寫代碼，那么和人的溝通能力依然是你跨不過去的瓶頸。寫代碼本身就是一種溝通，一種書面溝通。
程序?qū)懗鰜硎墙o人看的，附帶能在機器上運行。
--《計算機程序的結(jié)構(gòu)與解釋》
溝通從來都是個問題，書面溝通同樣困難。
爭論與無奈
程序員產(chǎn)生爭論的地方多半都在和同行的溝通中，想必很多人都和同行有過關(guān)于技術(shù)方案的爭論。我自己就曾在過去多年的工作中和同事有過技術(shù)方案之爭，得到的教訓可以建議給技術(shù)經(jīng)理（主管）們：不要讓兩個都覺得自己很牛的程序員去同時設(shè)計一個技術(shù)方案。不巧，你已經(jīng)這么干了并得到了兩個不同的方案，那么記住，就別再犯下一個錯：讓他們拿各自的方案去 PK。
既然分歧已經(jīng)產(chǎn)生了，為了避免無謂的爭論，該怎么解決呢？
