What Resonated This Week ?
#1 - 提高產出的秘訣
Source : (Book) 流量寫作密碼：日本暢銷書編輯破百萬點閱的寫作指南，自媒體時代必備的寫作力
自從開始 Weekly-Reflection 計畫，我希望能夠藉由「寫作」來練習產出資訊。
只是我沒有想到：這真的很難。
我打開編輯器，打出一段文字後，推敲修改、刪刪減減，如此循環一小時後，內容仍是寥寥數行，最後帶著對自己的失望，關掉編輯器。
剛開始寫作時，大概有六成的時間都處於這種狀況：充滿抱負的開頭、歷經掙扎、最後帶點遺憾的離開。
閱讀「流量寫作密碼」時，提到了一個概念，改變了我寫作的方式：
寫作時，把自己切分成不同的角色：「天真的寫作者」和「嚴厲的編輯」
「天真的寫作者」意味著「想到什麼就寫什麼」，而「嚴厲的編輯」則是嚴謹的檢查文章中有無贅字、概念是否連貫。
我覺得關鍵就在：不要在寫作時，同時讓這兩個角色出現。
過往當我在產出內容時，常常會在腦海中構思一個點子，接著馬上評斷、否決自己的想法，如同寫作時，寫一個句子，就開始思考：「這段文字是不是有點詞不達意？該怎麼修正才好」。
這樣的做法相當耗神，而且當我終於產出一段文字後，我的大腦已經精疲力竭。
實際將這兩個角色拆開後，明顯感受到自己過去寫作時的凝滯感降低許多！在「寫作者」模式，讓自己的文字隨著思緒自然流動，就算寫出口語化的贅字、重複的連接詞也無所謂，因為後續還會有「精修」的流程。
由於「寫作者」無所顧忌，對於「編輯」來說，能夠擁有大量的素材進行精修。
我發現不只是「寫作」，所有的「知識產出」行為都很適合拆分「寫作者」和「編輯」，我自己套用這個概念後，自覺「產出」效率有顯著的提升。
#2 - HQ&A 筆記法
Source : 如何透過 Obsidian 幫助知識工作者寫作 ? 分享我的 Obsidian 寫作流程
在實際寫卡片的當下，不要寫一個概念就新增一則筆記。而是在同一則筆記當中，將每一個概念分別用 HQ&A 筆記法的格式寫下來。
前陣子開始接觸到「卡片盒筆記」(Zettelkasten) 的概念，我很喜歡它將筆記拆分為「一則概念」的大小，並且藉由連結這些「概念」，來創造知識間的連結。
我試著在 Obsidian 中實作，卻發現遇到兩個問題 :
- 太麻煩！當我需要做筆記時，還需要思考如何拆分筆記。
- 拆分的筆記，到底該如何精準命名？
在朱騏的這篇文章中，提到三個很棒的概念：
- 寫筆記時，不用拆分成很多則筆記，而是透過章節劃分
- 寫筆記時，不需要在當下就按照概念分拆筆記
- 將「相對獨立的概念」單獨記錄在一個小節
- 藉由 HQ&A 方法找出「概念」筆記的標題
- H (Highlight) : 記錄的重點、感想
- Q (Question) : 如果這些 Highlight 的內容是一個「答案」，那麼「問題」會是什麼？
- A (Answer) : 用自己的話來回答問題，這個答案，通常就會是很棒的筆記標題。
- 在閒暇時刻，再把這些 HQ&A 的小章節，各自拆分為獨立的筆記，並且建立適當的連結。
對我來說，這種作法兼顧了「寫筆記時的效率」和「卡片盒筆記的連結」，推薦給卡片盒筆記的愛好者。
#3 - 回饋的價值
如果問我在網路上發表文章至今，什麼時刻最有成就感？
我的答案是：當陌生讀者主動聯絡，產生互動的時刻。
這種感動，我曾經歷過兩次，都是在 FB 收到陌生訊息，因為看到某篇文章而有所共鳴（有些人是遇到問題），希望能夠進一步聊聊，記得有位讀者甚至還通了半小時的電話。
儘管曾看過一本書提到，寫作的關鍵在於：「你能寫出多少沒人按讚的文章？」，但是對我來說，因為文章而產生的互動，會讓我感覺：原來我所寫的內容，是確實能帶給別人一些刺激的。
因此，我不禁開始反思，既然身為作者的我，會渴望讀者的回應，那麼扮演讀者角色的我，是不是可以多做點什麼呢？
最近當我讀到不錯的 Blog 文章時，如果作者有提供留言機制，我開始嘗試給予我的回饋或是感想，目前收到的作者回覆也都相當友善。
我想對於知識產出者來說，收到讀者的回饋都是正向的吧！希望藉著這樣的互動，建立一種正向的能量傳播 (笑)。
#4 - 被「測試」拯救了！
六月上旬，一位部門同事離職了，在他離職前一天，主管指派我負責接手其中一個項目。
在一天內接手完全陌生的項目，姑且先不論這樣的安排是不是有點怪味，我比較在意的是：面對一個完全陌生的項目，我該如何 Dive in ?
除了基本的 README 要寫好，在後續 Trace Code 的過程中，我發現「Testing Case」扮演了很重要的角色。
在口頭交接時，通常會著重在「設計緣由」、「項目如何劃分」等比較 High-Level 的「理念」，畢竟你需要先了解設計者的「理念」，才能用相同的視角去了解程式碼。
而底層的實作細節，可以藉由閱讀 Code 來了解，只要不是 Ninja Code，通常不會有太多問題。
我覺得真正缺乏的是：「這些封裝好的模組，彼此是如何互動的？」，這件事情不見得會被完整記錄在文件中 (就算有，可能也不完全)，卻難以在口頭交接的場合一一陳述。
但在 Testing Case 中，為了要測試元件的行為，通常會從「元件預期被執行的方式」去撰寫測試，這意味著在 Testing Case 中，其實蘊含著：「作者希望這元件如何被執行」。
而這件事情，對於新加入的開發者來說，其實是非常好的 Entrypoint。
這一次，可以說我被 Testing Case 拯救了。
我也開始反思，如果未來轉換工作，我手上的項目該如何更好的交接給其他人呢？
我想是時候規劃測試了。