我們程序員可以從解決的諸多問題中獲得自豪感，比如說編寫了最節(jié)省時間和空間的算法；設(shè)計了高度可擴展的架構(gòu)；巧妙地為函數(shù)和變量命名；

創(chuàng)建的應(yīng)用程序獲得了五星級評分，甚至影響了全球許多人的生活。為了獲得這種自豪感，我們需要戰(zhàn)略性地規(guī)劃我們的職業(yè)生涯，不斷提高我們的技術(shù)技能。

為了提高我們的技術(shù)技能，我們花費大量時間和金錢來學(xué)習(xí)成為全棧和跨平臺人才；每天都會在 Hackerrank 或 Leetcode 中進行 CS 理論和實踐的復(fù)習(xí)；

常常購買有關(guān)最佳實踐和設(shè)計模式的書籍；致力于業(yè)余項目以維護自己在 Github 上的活躍度；

通過回答 StackOverflow 上的問題來培養(yǎng)“聲譽”——為了提升自己，我們還有很長的路要走。

所有上述這些通常都是以犧牲一個人的軟技能為代價的。

軟技能是人們在進行自我管理，以及與共事者（例如客戶和同事）交往的過程中所使用的技能，包括領(lǐng)導(dǎo)力、情商、說服及傾聽的能力、對同伴的激勵，以及建立有價值的關(guān)系。

而硬技能則是指在解決問題或生產(chǎn)產(chǎn)品時所運用的高度專業(yè)化的科學(xué)知識。

通常情況下，大家都慣于認(rèn)為“硬技能”掌握起來相對困難，軟技能就簡單易學(xué)——其實這是一種誤解。實際上，如果自己未能意識到這一點并花費大量時間深入思考，軟技能其實難以掌握。

溝通，或者說是將想法或信息傳達(dá)給另一個人的能力，就是這樣一種常被忽視的軟技能。

和很多年輕的程序員一樣，我也曾默認(rèn)那些被指派直接與我合作的人，應(yīng)該對技術(shù)原理有深刻的理解且無需我再做過多解釋。

否則，他們要么不應(yīng)該在科技行業(yè)工作，要么就是白癡。

許多年輕程序員認(rèn)為正式的文檔和流程只是官僚主義的繁文縟節(jié)，只會拖緩軟件開發(fā)的進度，因此不應(yīng)推行。

在傳奇人物的宣傳報道中，我們更是多見性格內(nèi)向且多怪癖的大牛，但膜拜之余我們?nèi)圆坏貌怀姓J(rèn)他們大多很難合作。

程序員必須學(xué)會溝通。

首先，絕大多數(shù)編程活動都是在程序員與非程序員交互的組織內(nèi)部完成的。

通常，我們必須與產(chǎn)品經(jīng)理溝通，以充實業(yè)務(wù)需求的技術(shù)細(xì)節(jié)，以便衡量難度，評估可行性，并基于這些因素，優(yōu)先考慮任務(wù)；

我們有時需要向項目經(jīng)理提供評估并證明其合理性，項目經(jīng)理則要確保項目符合預(yù)算要求并按計劃進行；

我們需要與設(shè)計人員密切合作，以解決目標(biāo)環(huán)境的局限性，識別用戶在交互中缺少的流程，或發(fā)現(xiàn)信息設(shè)計的問題。

在與扮演這些角色的同事溝通時，我們必須時刻關(guān)注用于傳達(dá)我們想法的詞語或語氣。

高績效團隊的一個關(guān)鍵因素是團隊動力，如果我們在溝通中用了過激的方式而導(dǎo)致沖突，那么團隊中就會形成隔閡以至于大家不能高效工作。

有人可能會問，為什么還有這些其他角色存在？

沒有什么能阻止程序員直接與客戶聯(lián)絡(luò)并收集需求；當(dāng)瀑布模型（Waterfall Model，一種項目開發(fā)架構(gòu)）比 Scrum 更受歡迎時，產(chǎn)品經(jīng)理或許已成為過去；程序員也可以直接與 CEO 聯(lián)系并使用純邏輯來證明產(chǎn)品開發(fā)的可行性。

設(shè)計師也將逐漸失去存在的價值，任何編碼器都可以使用自定義字體、顏色和圖標(biāo)甚至是矢量，而不是JPG。

我們自己能夠編寫單元測試的情況下，為什么還需要一個專門的測試人員團隊？

真正有價值的成功產(chǎn)品是那些在規(guī)模不凡且需要多學(xué)科專業(yè)知識的產(chǎn)品。

因此，好的產(chǎn)品不可能靠誰獨自完成。代碼本身并不是一種商業(yè)行為。事實上，上述角色所涉及的工作內(nèi)容往往需要花費大量的時間和精力才能完成，特別是在堅持高標(biāo)準(zhǔn)的情況下。

如果程序員以一己之力挑起所有活，那么無疑啥都做不好。即使做了也只會消耗掉原本可能專注于編寫代碼的時間，這才恰恰是程序員的主要任務(wù)。

另外，以這種方式否定同事的作用也是一種傲慢無知且目光短淺的行為。

產(chǎn)品經(jīng)理為不僅僅基于我們的定位編寫業(yè)務(wù)需求——這只是程序員工作的一部分——他們還通過不斷研究客戶行為和公司業(yè)務(wù)領(lǐng)域的趨勢來保持產(chǎn)品的價值；

項目經(jīng)理做的也不僅僅是證明估算的合理性——他們還會計劃和調(diào)整時間表、預(yù)算，同時評估風(fēng)險并管理資源分配；

設(shè)計師除了培養(yǎng)對藝術(shù)的良好品味外，還研究了大量心理學(xué)、人機交互、甚至神經(jīng)科學(xué)，就是為了將科學(xué)發(fā)現(xiàn)融入公司的產(chǎn)品中；

測試人員不同于僅僅在開發(fā)環(huán)境中工作的單元測試，他還需要確保產(chǎn)品在部署到生產(chǎn)環(huán)境之后仍然按照預(yù)期的方式運行。

他們在消除開發(fā)人員偏見，思考“Unhappy paths”，記錄錯誤重現(xiàn)的步驟，系統(tǒng)化測試工作流以及自動模擬用戶交互方面（大多數(shù)開發(fā)人員認(rèn)為這是一項苦差事）具有無可估量的價值。

程序員若跳出屏幕，外面的世界要大得多。我們應(yīng)該保持謙虛，因為我們可能沒有足夠全面的知識來了解與我們角色不同的人的日常工作和責(zé)任。

的確，我們不能籠統(tǒng)地稱呼那些不敲代碼的人為“非技術(shù)人員”，因為他們而實際上是他們所擅長領(lǐng)域的技術(shù)人員，在他們的領(lǐng)域里我們也不過小白而已。

然而，溝通技巧的重要性或許不僅是因為需要與非編程角色互動，還在于需要與其他程序員進行溝通。

我們經(jīng)常就一些抽象問題進行辯論，爭先恐后地解釋為什么這個好，那個棒，這個流程或框架優(yōu)于另一個，以免我們的觀點因帶上了個人偏好而被忽視。

很多時候，工程團隊都會做出一個架構(gòu)決策，甚至不是因為它客觀上比其他選擇更好，而只是因為這個選擇更有說服力。

我們也經(jīng)常討論并商定工作標(biāo)準(zhǔn)，例如版本控制工作流程和代碼風(fēng)格。我們喜歡互相教授高級編程技術(shù)和行業(yè)最佳實踐。

最終，隨著我們晉升到更高的職位，一對一地進行交流，提供反饋和管理沖突的責(zé)任變得不可避免。

其他人可能會爭辯說，如果僅以“服從命令”為需求來聘請程序員，就不需要溝通技巧。

然而，即使是僅遵循項目開發(fā)指令的程序員，仍然需要通過溝通確保不可協(xié)商的要求得到充分理解。

即使是實習(xí)生和初級軟件工程師，如果發(fā)現(xiàn)規(guī)范中存在錯誤，或者是在存在歧義的地方提出問題，也應(yīng)該能夠表達(dá)出來。

因此，溝通是程序員的核心技能。