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