01，為何他們可以，但我不行
Weekly Review，也就是週記，主要內容為：從我本週的 Logseq 日誌中，挑 1-3 則作為公開記錄發表。
自從使用 Logseq 後，我每天日誌中的筆記數，介於 5-15 則之間，且絕大部分都不是每天固定記錄的內容。有些事，若只留在筆記中，未免有點可惜，所以想成文並發表出來。這樣的「創作摩擦力」也相對低，雖然依舊需要一定的編輯。
這系列主要是為了記錄，自己對一些重要事情的思考與反省。而公開發表有助於強化這些事物的影響與形成，無論是對外還是對內——因為不再只有我自己知道。
內容同步更新於部落格的「Weekly Review」分類，兩者的主要差異是 blog 本文中會帶超連結，臉書就算了，會影響版面。
三個主要限制
此外，為了進一步降底寫作摩擦力，我對這系列有三個主要限制，以及一些細節限制。比如只在週末發文、不過度編輯等等，這部分還在發展中，可都先略過不提，在此只講主要限制。
而且，雖說是「限制」，但本質上其實是一種基於我的價值觀的「自我保護機制」。換句話說，有了固定的形式，能一定程度避開不必要的枝節與煩惱，這是我所喜歡的。
限制一：不定期
雖然如朱騏所言，類似電子報這種每週必定要產出內容的模式，有助於逼自己進步，但對我而言也存在一些疑慮，比如材料不足時，為了滿足讀者期待與自己的週更承諾，還是要硬湊，或花費額外的時間取材。
考慮到我的價值觀與喜好節奏，還是不要太逼自己才好——除非它真的很重要。現在還不是。
不過，不定期只是指「不一定會每週都會寫」，話雖如此，我還是會盡可能在每個週末發文。但若是沒有什麼值得記錄的事，或我太懶惰，索性就直接略過。
此外，不定期的另一個好處就是：當我想半途而廢的時候，甚至不必附上一個太認真的理由——都說是不定期了嘛！——凹嗚！
限制二：固定結構
目前中文創作者中，常見電子報內容架構主流之一是仿效 James Clear 的 《3–2–1 Thursday newsletter》這種。我畢竟也不是寫電子報，就不必了，取裡面的這個「3」就好了——最多 3 則，最少 1 則（最少其實是 0，就是沒發文）。
固定結構也有助於我在部落格同步更新，畢竟只要寫在 blog，我的毛就特別多，不限制不行。
限制三：字數
原則上要遵守臉書發文的 1000 字篇幅上限，除非有特殊理由——比如這個第一期，必然就得多解釋一點來建立「世界觀」。
還是那句話：在我的價值觀中，想要追求更多，就得要先「限制」才行。我日後的所有言行，也都會圍繞著這個核心思想運作。
以上是前言，之後的前言就會短的多，以下是內容，本週為兩則。
一、為何他們可以，但我不行
這裡的他們，指的是可以大量且持續產出的文字創作者，比如瓦基或朱騏。雖然標題很像在比較，但主要想著眼於——我對自己目前「寫作產出速度」的苦惱。
從〈Hexo 部落格心得：一週年總結與持續寫作策略〉這篇心得後，我確立了「寫少但寫得更好」的部落格發文基調。所以第二年的發文速度，可謂進一步減緩！
但 4 個月下來，竟然只有發表了 5 篇文章，這也太少了（雖然有 4 篇是長文）！且不符合原先的預計：一個月應該要有 2 篇。
我可以接受不大量，但也「數量」上還是有個底限，且發文週期沒有明確的規律，顯然有必要改善一個這個「不健康」的狀態。
二、程式設計：如果這樣寫可以，那樣寫「也可以」——那就是「不可以」
最近工作上又在大量重構既有的程式碼，這無疑是一個考驗血壓的場合。
在此過程中，我實實在在地領略到了〈Zen of Python〉中的這句：
There should be one——and preferably only one——obvious way to do it.
它遠遠不止適用於 Python。
比如 SQL 的 table schema，欄位要不要 null=true，要不要給定預設值，這些設計，都應該盡可能確信且嚴謹。
如果你隨便設，程式確實可以隨便通過、正常運行，這聽起來似乎是好事？但等到發生問題的時候，這種「高度容錯」的困境，會讓你的 debug 之旅猶如大海撈針。
一言以蔽之，好的程式邏輯應該是：該出錯的時候，一定要出錯，背後行為邏輯才會足夠清晰、好維護。
就像工作上，假如你遇到了一個明顯超過自身能力的瓶頸，此時絕對不要「埋頭苦幹」（這有時比拖延還可怕）或乾脆逃避，請勇於請教同事或反映主管，不然最終都要有人要幫你擦屁股。
「這樣可以，那樣也可以」——就是不可以。