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 部落格寫作一週年:完整心得與總結 + 如何持續寫作 Part 2〉這篇心得後,我確立了「寫少但寫得更好」的部落格發文基調。所以第二年的發文速度,可謂進一步減緩!

但 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 之旅猶如大海撈針。

一言以蔽之,好的程式邏輯應該是:該出錯的時候,一定要出錯,背後行為邏輯才會足夠清晰、好維護。

就像工作上,假如你遇到了一個明顯超過自身能力的瓶頸,此時絕對不要「埋頭苦幹」(這有時比拖延還可怕)或乾脆逃避,請勇於請教同事或反映主管,不然最終都要有人要幫你擦屁股。

「這樣可以,那樣也可以」——就是不可以