前言
- 我發現自己有時候明明是在問 Why，卻不知不覺開始思考具體事項，所以先記下來提醒自己要注意
抓住核心就會很輕鬆
- 如果高層次的抽象沒有偏掉，就會比較輕鬆
- 像職涯技巧、黑帽 SEO、遊走灰色地帶之類的做法，並沒有提升本質價值，而是把具體細節算得很精密再去執行，所以一點小失誤都不被允許，會很辛苦
- 所以沒有必要徒勞地去想複雜的事情
- 以錯誤的設計去實作也同樣是件很辛苦的事
- 如果 why 很明確，就算沒有細想小地方，之後也能說明清楚
比效率化更前面的事
- 效率化是一個危險訊號。那也許只是你在照著別人的指示做事
- 在使用軟體的商業脈絡中，不只是效率化或實現功能，而是把焦點放在提升顧客營收上，視角才會提升到 why
- 規劃與問題，其實比效率化更前面。去效率化那些無關緊要的事也沒有意義
- 規劃、提案先腦力激盪，再刪減，似乎會比較好
把人看得重要一點，平衡感或許比較好
- 雖然可能還有更高層次的東西，但若要在資本主義經濟與文化化的現代人之中生活，就必須思考人
- 對人類抱持興趣，帶著有點熱血、像是「一起過上好人生吧」的態度
- 相信人的可能性
- 持續提問
- 捕捉一些微妙的違和感與詞句
- 每個人手上擁有的資訊都不同
追求答案，反而會變得很狹小
- 帶著興奮感；甚至妄想也沒關係
- 沒有得出答案並不是壞事
- 禪問答。持續追問為什麼
- 認為「沒有意義」這種想法，本身也沒有意義
拋棄實作者的思維
- 不要用「實作與介面定義書的對照」那種方式去閱讀
- 不要去想實作，特別是資料庫造成的資料持久化
思考比現在更前面的事情，反而會變得很狹小
- 讀的時候不要邊摘錄或做筆記。就只是聽。若真的很難，就想像情境，特別是情感強烈波動的點
- 告訴自己「只有現在能聽」，忍耐著一直聽下去
- 不要去想能不能實現。那是後面的階段
- 不要把交付的現實性，或像「A 和 B 做成 C」這種式子套上去。只要這麼做，就會變成 how
- 把實作與設計文件對齊，像是 DDD 的一種解讀；若是「處理複雜性」，則是更高層次的抽象
專家與外行
- 外行判斷會造成錯誤（包括非系統面的錯誤）；外行提問則是解決問題的關鍵
- 所謂專家（職人），就是擁有更多、更高品質的默會知識的人
- 透過由領域外行、但在具體化方面經驗豐富的工程師，將默會知識轉化為語言，進而成為適切的明確知識。軟體的價值就在於能將可商品化的部分商品化
- 要依賴專家的默會知識，並把它傳遞出去
- 人類是透過身體經驗來獲得默會知識的。若以語言表達，資訊會流失，所以這部分對 LLM 來說似乎很難。不過，即使是為了取得默會知識，在 LLM 能寫程式的時代，寫程式這件事仍然很重要
共有 0 則留言
文字內容提供幾種功能：
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
熱門文章
