溝通！ | The Pragmatic Programmer 20週年紀念版

I believe that it is better to be looked over than it is to be overlooked.
— Mae West, Belle of the Nineties, 1934

核心概念#

不只是你擁有什麼，還有你怎麼包裝它。
擁有最好的想法、最棒的程式碼，或最務實的思維，如果你無法與他人有效溝通，最終都是徒勞的。
好的想法如果沒有有效溝通就是孤兒。

作為開發者，大部分時間都在溝通：
會議中聆聽和談話、與終端用戶合作、寫程式碼、寫提案和報告、在團隊中倡導想法。

Tip 11 - English is Just Another Programming Language（英語只是另一種程式語言）
把自然語言當作你寫程式碼一樣對待：遵循 DRY 原則、ETC、自動化等。

商業溝通中最困難的部分是弄清楚你到底想說什麼。
寫大綱，然後問自己：「這能以對我的受眾有效的方式傳達我想表達的嗎？」反覆精煉直到可以為止。

你只有在傳達你想傳達的意思時才算是在溝通。
你需要了解受眾的需求、興趣和能力。

對不同的受眾，用不同的方式呈現同一個技術更新。收集回饋，持續改進你對受眾的了解。

讓你說的話在時間上也相關。
有時只需要問：「這是個談論…的好時機嗎？」

根據受眾調整你的交付方式。
有些人想要正式的「只要事實」簡報，有些人喜歡先閒聊。
他們的技術水平如何？如有疑問，直接問。

你的想法很重要，它們值得一個好看的載體。
花時間學習排版和格式工具。
檢查拼字——先自動檢查，再手動檢查。

如果可能，讓讀者參與文件的早期草稿。
取得回饋，建立良好的工作關係。

如果你想讓別人聽你說話：傾聽他們。
如果你不聽他們的，他們也不會聽你的。鼓勵別人發言，把會議變成對話。

總是回覆郵件和留言，即使回覆只是「我稍後回覆你」。
讓人們保持知情會使他們更容易原諒偶爾的疏忽。

Tip 12 - It’s Both What You Say and the Way You Say It（既是你說什麼，也是你怎麼說）
溝通越有效，你就越有影響力。

Tip 13 - Build Documentation In, Don’t Bolt It On（將文件內建，而非外掛）

務實的程式設計師將文件視為整體開發過程的一部分。
但這不代表每個函式、資料結構、型別宣告都需要自己的註解——這種機械式的註解寫法實際上讓維護更困難。

限制非 API 註解討論為什麼做某事、它的目的和目標。
程式碼已展示了怎麼做，對此加註解是多餘的且違反 DRY 原則。

技巧： 註解原始碼是記錄工程取捨、決策原因和被放棄的替代方案的絕佳機會——
這些是無法在其他地方記錄的。

關於寫作的一切也適用於電子郵件、社群媒體貼文和部落格：