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

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

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

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

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

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

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

而硬技能則是指在解決問題或生產產品時所運用的高度專業化的科學知識。

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

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

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

否則，他們要么不應該在科技行業工作，要么就是白癡。

許多年輕程序員認為正式的文檔和流程只是官僚主義的繁文縟節，只會拖緩軟件開發的進度，因此不應推行。

在傳奇人物的宣傳報道中，我們更是多見性格內向且多怪癖的大牛，但膜拜之余我們仍不得不承認他們大多很難合作。

程序員必須學會溝通。

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

通常，我們必須與產品經理溝通，以充實業務需求的技術細節，以便衡量難度，評估可行性，并基于這些因素，優先考慮任務；

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

我們需要與設計人員密切合作，以解決目標環境的局限性，識別用戶在交互中缺少的流程，或發現信息設計的問題。

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

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

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

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

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

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

真正有價值的成功產品是那些在規模不凡且需要多學科專業知識的產品。

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

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

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

產品經理為不僅僅基于我們的定位編寫業務需求——這只是程序員工作的一部分——他們還通過不斷研究客戶行為和公司業務領域的趨勢來保持產品的價值；

項目經理做的也不僅僅是證明估算的合理性——他們還會計劃和調整時間表、預算，同時評估風險并管理資源分配；

設計師除了培養對藝術的良好品味外，還研究了大量心理學、人機交互、甚至神經科學，就是為了將科學發現融入公司的產品中；

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

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

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

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

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

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

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

我們也經常討論并商定工作標準，例如版本控制工作流程和代碼風格。我們喜歡互相教授高級編程技術和行業最佳實踐。

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

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

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

即使是實習生和初級軟件工程師，如果發現規范中存在錯誤，或者是在存在歧義的地方提出問題，也應該能夠表達出來。

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