開發人員應該與同行分享更多知識。 請遵循這些提示來克服焦慮並開始寫部落格（或寫得更好）。
翻譯自 Charles Humble 的 Writing for Software Engineers： Read Me First。 很不錯的寫作教材，上一本是陳浩老師翻譯的《谷歌技術寫作》，這裡我還記得陳浩老師。 在這裡找到第二部分。 我們許多工程師都患有一種常見的疾病：害怕寫作。 這通常從學校開始，在那裡我們被告知我們沒有“語言天賦”。 這是無稽之談。 寫作是一門手藝，它的原理是可以學習的。
您可能想要這樣做的原因有很多。
隨著越來越多的人轉向遠端和混合工作，以書面形式清晰溝通的能力變得比以往任何時候都更加重要。 寫作是建立個人品牌的絕佳方式，在此過程中，它迫使您學習和發展。 提高你的寫作技巧也可以幫助你在職業生涯中取得進步。 如果你渴望從事管理或開發人員關係工作，想讓自己成為會議發言人，甚至夢想有一天為技術出版商寫一本書，那麼寫作（以及上述品牌）是實現這些抱負的核心。 此外，它讓你有理由與其他知識淵博的人交談，而且它既刺激又有趣且困難。 我認為，作為工程師，我們被困難的問題所吸引。 寫作和程式設計之間也有一些驚人的相似之處。 有些是顯而易見的。 與程式設計一樣，寫作可以通過練習來提高。 與程式設計一樣，您經常通過模仿來學習新的寫作技巧。 就像程式設計一樣，寫作中有一些模式可以派上用場，但這些模式也很誘人、令人困惑，並且容易被過度使用。 你的潛意識也比你想象的要多寫作（或程式設計）。 你可能會花一整天的時間在一篇文章或乙個段落中為乙個問題而苦苦掙扎，只是在休息後才弄清楚。
我堅信，工程師需要提高他們分享知識的能力，而寫文章是實現這一目標的關鍵途徑。 作為一名前工程師和首席技術官，現在主要是一名作家和顧問，我將分享我的方法，希望它能鼓勵你們中的一些人分享更多的知識。
考慮到這一點，我將從分解我的寫作過程開始。 當然，每個人的創作實踐都略有不同。 但是，考慮某人如何處理工作可能是乙個有用的起點。
我喜歡從思考我為誰寫作開始。 我發現在開始之前有乙個清晰的人是有幫助的。 這樣做的好處之一是您可以回答諸如“他們知道什麼？ “以及”我需要解釋多少？ “這樣的問題。
例如，你可能會想，“我正在為乙個高階開發人員寫這篇文章，他的第乙個領導角色。 他們可能已經專業編碼了大約七八年，但還沒有領導過乙個團隊。 ”
“或者，”這適用於初級開發人員（可能是第乙份工作或第二份工作），他們將 AWS Lambda 用於他們的第乙個專案。 他們知道 GO，因為他們在大學裡學過 GO，但他們對構建 lambda 專案知之甚少。 當然，“這是兩三年前寫給像我這樣的人的文章，在我了解這些事情之前”也是乙個很好的（也是常見的）起點。
知道你在為誰寫作的乙個原因是，它可以幫助你識別一些或所有目標受眾不熟悉的術語。 如果某個術語不熟悉，您可以：
鏈結到乙個很好的解釋（不要再次強調明亮的輪子）。
如果找不到好的鏈結，請提供簡短的定義。
如果您有很多這些術語，最好提供乙個詞彙表。 一旦我決定為誰寫作，我就會決定我將為該讀者扮演什麼角色。 我是記者嗎？ 教育 工作者？ 只是乙個普通的程式設計師？
然後我問：“我想涵蓋多少，我想說的一件事是什麼？ “這很重要，因為所有作家都渴望完整性和準確性。 我在這裡最好的建議是從小處著眼。 決定你想涵蓋主題的哪個小角落，並盡可能地做到。
我問自己的下乙個問題是，“寫了什麼？ ”
我建議在開始時設定乙個字數預算。 例如，500 字適合推出新工具或產品並簡要描述其功能——基本上，這是乙個新聞報道。 對於部落格文章或類似文章，1000 到 2000 字是標準字數。 教程（尤其是那些有很多例子的教程）和書面採訪或面試可以更長一些，但要始終保持簡潔。
如果一篇文章最終真的太長了，請考慮是否可以將其分成兩個或多個部分。 但請注意，網際網絡上充斥著第一部分的文章，而不是第二部分，因此請嘗試在發布第一部分之前寫整篇文章。
還有一些其他的決定需要事先做出。 乙個是，你想用第三人稱（作為觀察者）還是用第一人稱（作為參與者）寫作？ 乙個相關的問題是你打算使用什麼時態; 大多數人主要用過去時寫作（“前幾天我試著用圍棋寫作”），但你也可以嘗試用現在時態寫作（“我坐在飛往三藩市的飛機上，同時黑客攻擊了一些圍棋**”）。
無論你決定做什麼，都要堅持下去。 讀者在段落中在視角和動詞時態之間來回切換可能會讓人感到不舒服。
要提前考慮的另一件事是您是否需要進行任何面試。 對於您自己的部落格，通常也適用於企業部落格，您將表達一種觀點。 對於外部出版物，您更有可能需要不止乙個並進行面試才能獲得。 在這裡維護您的網路非常有幫助，這樣您就擁有了乙個可以輕鬆連線的網路。
在面試之前，我通常會寫乙份粗略的初稿，以找出我想填補的空白。 然後我會在聯絡之前預先計畫問題。 面試將預先計畫的問題與即興對話相結合，但我發現計畫對於獲得良好的結果至關重要。
通過電子郵件、Zoom** 等會議平台或親自進行面試。 我曾經被電子郵件所吸引，但隨著我經驗的增長，我開始更喜歡面試而不是電話。 與其手忙腳亂地做筆記，不如在受訪者的許可下錄製**或**次採訪，一些人工智慧（AI）驅動的應用程式可以提供語音到文字的轉錄，使其更容易準確引用**。
如果我作為編輯的經驗有什麼可以佐證的話，那就是作家似乎對他們的初稿有一種奇怪的依賴感。 盡量避免它。 相反，把你的初稿看作是通過適合你的方法探索你的問題領域，而不是一開始就編寫測試用例或繪製UML圖。
當你開始寫作時，你經常會發現材料朝著你意想不到的方向流動，你做出的一些前期決定可能不是正確的。 這不重要。 讓素材帶你去它想去的地方，然後稍後回顧和完善它。
當我開始乙份工作時，我不會過多地考慮它的發展方向。 我發現空白頁令人生畏，所以我傾向於在螢幕或紙上寫下文字，而不考慮太多，然後在拿到草稿後組織它們。
我還發現，如果我用手寫而不是在螢幕上打字，我的寫作風格就會大不相同。 我通常使用計算機，但我覺得值得嘗試這兩種方法並找出最適合您的方法。 我有閱讀障礙，所以我試著通過聽寫來寫作，但結果對我來說從來都不滿意，但你可能會得到不同的結果。
你必須善於丟棄材料。 我經常發現我最終刪除了原始草稿的前兩三段，因為它們不夠好; The New Stack 的主編希瑟·喬斯林 （Heather Joslyn） 將這些一次性段落稱為“清嗓子”，我喜歡這一點。 你會驚訝於我編輯了多少篇文章，其中我會刪掉前幾段作為開頭。 我在 Pages 中起草，部分原因是我使用 mac，部分原因是我不覺得它很突兀，但主要是因為我知道我會在其他地方提交這篇文章——通常以 Markdown、HTML 或 Google Docs 的形式，具體取決於出版商。 這類似於為應用程式製作一次性原型，我們在現實世界中並不經常這樣做，但可能很有用。 在一堂關於講故事藝術的大師班上，作家尼爾·蓋曼（Neil Gaiman）說：“做第二稿是讓它看起來像你一直在做你所知道的事情的過程。 “我通常會去 Google Docs 做第二稿，因為它支援跟蹤更改和版本控制，這有助於編輯、允許評論，並且非常適合協作。 開源 Docs to Markdown 外掛程式雖然並非完全沒有漏洞，但通常擅長將 Google Docs 中的文字提取為 HTML 和 Markdown，具體取決於您的內容管理系統需要什麼。 第二稿是我開始思考作品結構以及它是否合乎邏輯的地方。 這就是了解你的讀者真正開始帶來好處的地方，因為你可以問自己這樣的問題，“這個人首先想知道什麼？ “這樣的問題。
如果我在沒有編輯的情況下工作，一旦我對手稿感到滿意，我就會找其他人——通常是我飽受折磨的妻子——來閱讀我的第二稿。 如果我與編輯合作，我通常會向他們傳送第二稿。
在發布或提交之前，我通常會將草稿傳送給我採訪過的任何人，以確保他們對自己的報價感到滿意。 它有助於在未來的面試中培養聯絡，並有助於防止訴訟。 我也經常以這種方式收到有用的反饋; 我只遇到過乙個主要問題，受訪者想要做出很多改變。
如果你在易受影響的年齡讀過《四人幫》一書，並發現自己在**中到處都在使用工廠方法和裝飾器，你就會熟悉模式的問題之一：它們很有用，但過度使用它們很誘人。 公式化寫作的名聲不好，但記者和所有作家一樣，有時會依賴久經考驗的模式，我認為學習一些模式沒有任何壞處。
倒金字塔結構是使用最廣泛的書寫模式之一。 它通常用於新聞業，但它也廣泛用於各種其他型別的文字，包括部落格、社論專欄和營銷材料。
將其視為重要性的降序層次結構。 從最有價值的事實開始，然後使用段落來支援論點，然後越來越深入。
這種結構的關鍵是開頭段落，它應該以清晰簡潔的方式總結最重要的資訊，以激起讀者的興趣。
在這個結構中，最重要的句子是第一句話。 如果你的讀者不想讀第二句話，你的文章已經很冷了。 訣竅是寫出吸引讀者的句子，並不斷鼓勵他們讀到最後。
以下是 The New Stack 的新聞編輯 Daryl K. Taft 撰寫的新聞開場白示例：
“儘管最近關於Microsoft為了Rust而不經常使用C程式語言的喧囂，但Microsoft表示它仍然致力於C你可以從這句話中學到很多東西。 你可以看出很多人都在說 Microsoft 放棄了 C 語言而使用 Rust 語言，你可以推斷 Microsoft 肯定在自己的專案中使用了更多的 Rust。 您還可以了解到，Microsoft 對這一說法非常關注，以至於它已經發表了公開宣告來否認謠言。
敘事寫作通常用於報紙和雜誌的特寫鏡頭。 敘事分為兩部分：故事和講故事的人。 講故事的人更像是乙個劇作家或乙個家——描繪人們在生動的環境中相互交流。 它不常用於技術寫作，但它可以成為編寫案例研究的有效方法，例如。
寫這種文字的挑戰在於，你可能會忘記你想講述的新聞故事。 沙漏模式通常歸功於記者和寫作教練羅伊·彼得·克拉克（Roy Peter Clark），旨在將最好的敘事和倒金字塔風格結合起來。 沙漏的故事分為三個部分：
乙個倒金字塔，總結了頂部最值得注意的資訊。
一種講故事的方式，使作者能夠深入而詳細地展開故事。
標記兩種格式之間轉換的過渡或中心。
華爾街多年來一直使用焦點樣式，通常用於頭版專題。
就像沙漏一樣，焦點風格的廣泛目標是嘗試將敘事敘事和新聞寫作風格融合在一起。 它分為四個部分。 第一部分是關鍵介紹，不像倒金字塔，最長可達五段。 第二部分是結論段落，它的名字來源於它“簡潔”地總結了故事。 最後一段陳述了故事的核心部分以及線索如何表達觀點。
然後在正文中闡述了核心觀點，而結局則以令人難忘的曲折或評論將故事引向自然的結局。 我的文章“避免成功的災難：售票員泰勒·斯威夫特之戰”展示了它是如何工作的，結論段落出現在第五段，下面用紅色標記。 
在技術寫作中，這種風格往往略有不同，使用軼事或故事作為切入點和指南，然後通過關鍵段落作為風格化的轉折進入文章的核心。 這種方法之所以有效，部分原因是人類天生喜歡故事; 它在會議演講中也很有效，這就是為什麼大多數TED演講都是從軼事開始的。
您可以在 Jennifer Riggins 的文章“如何放火燒巨魔農場”中看到它是如何工作的。 在關鍵段落作為第四回合之前，她用三個段落（由下面的紅色邊框表示）來集中敘述。 
“結局”一詞是指故事的結局。 結局引發了無窮無盡的問題。 我認為其中乙個原因是，在學校裡，我們被教導文章有開頭、中間和結尾，結尾應該是以更簡潔的形式複述我們已經說過的話。
當你把“結論”放在副標題中，或者寫上類似“總而言之，你可以指出......你會知道你正在這樣做。 此時，您的讀者將聽到您的整篇文章發出吱吱聲。
這樣的結論會破壞你迄今為止所做的任何好工作。 乙個好的結局應該讓人感覺像是乙個自然而然的停下來的地方。 我使用的乙個技巧是檢視我的筆記，看看我是否能找到任何想要結束這篇文章的自然原因。 以下是我在 The New Stack 上發表的文章“About Ecstasy， a language designed for the cloud”中的乙個示例：
“我們已經為此工作了大約六年，我們現在才開始構建我們打算構建的實際專案，”Purdy說。 “這是你聽說過的通往最小可行產品的最長道路！ ”現在我已經介紹了基礎知識，請檢視本系列的第二部分，了解完善您的工作和吸引讀者注意力的技巧。