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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高績(jī)效團(tuán)隊(duì)的一個(gè)關(guān)鍵因素是團(tuán)隊(duì)動(dòng)力，如果我們?cè)跍贤ㄖ杏昧诉^激的方式而導(dǎo)致沖突，那么團(tuán)隊(duì)中就會(huì)形成隔閡以至于大家不能高效工作。

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

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

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

我們自己能夠編寫單元測(cè)試的情況下，為什么還需要一個(gè)專門的測(cè)試人員團(tuán)隊(duì)？

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

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

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

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

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

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

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

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

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

程序員若跳出屏幕，外面的世界要大得多。我們應(yīng)該保持謙虛，因?yàn)槲覀兛赡軟]有足夠全面的知識(shí)來了解與我們角色不同的人的日常工作和責(zé)任。

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

然而，溝通技巧的重要性或許不僅是因?yàn)樾枰c非編程角色互動(dòng)，還在于需要與其他程序員進(jìn)行溝通。

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

很多時(shí)候，工程團(tuán)隊(duì)都會(huì)做出一個(gè)架構(gòu)決策，甚至不是因?yàn)樗陀^上比其他選擇更好，而只是因?yàn)檫@個(gè)選擇更有說服力。

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

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

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

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

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

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