兩年完成 60+ 場的知識分享
- 發佈於
如果你有做過技術或知識分享，那你都分享什麼呢？
在 從害怕上台到擁抱舞台 提過我開始面對 org 作知識分享，但是我還是沒有習慣定期知識分享，直到這個故事的開端，讓我擁有了長達兩年，維持一週到兩週分享一次的知識分享會。
2023 年 4 月，我們 kick off 了 Monolithic 到 Microservice 的專案。
作為 owner 的我，很快我發現開始重複講同樣的東西——講給不同人聽，這讓我講到有點懷疑人生。像是 TypeScript 的設計概念、不同 tech stack 的應用、monorepo 的架構設計、library 和應用開發之間的思維轉換，這些東西我可能已經講過三次，還是會有第四個人問一樣的問題。
路過同事們在討論設計的時候，聽了一耳
「這樣應該過不了 Chin 的 review，上次她在我這 PR 有提到這個要注意——」
當時我心想，那我為什麼不一次講給全部人聽？
所以我想說既然每次都要講，那就寫下來，整理成分享，每週一場，大家一起來聽，讓資訊統一，還可以講一次就好，聽起來真的很棒？（當然事實證明我太天真）
轉折與焦慮#
於是，我開始把每週在專案裡出現的重點討論記下來，包含程式設計想法、規範建立背後的脈絡，甚至連「為什麼這邊要加一個 lint rule」這種微小的選擇只要有有趣的分歧討論也會納入。
而分享的初期很順利，每週都有內容。也有不錯的回饋。我也會在工作中觀察同事們常問什麼問題，把那些拆解成素材整理進來。進行到一兩個月時，除了 platform teammates 之外的 frontends 也聽說有這個分享會想加入，我當然不無不可的同意了。
故事並不是線性的順利開展下去，大家都覺得收穫良多，就有個歡天喜地的結局的。
我的小分享會變成面對全部的 frontend folks 的分享，這對我來說也變成了壓力。
一部分是跟原本分享的群體經驗有差異，另一部分則是工作上做的事情不太相同。
從起初的好玩有趣變成後來的焦慮，有時候擔心自己講得太表面，也擔心聽的人覺得無聊，我開始為每週要講什麼感到憂慮，準備分享變成焦慮而非期待。
我甚至開始想，我這樣每週講這些東西，真的對大家來說有意義嗎？
找回初衷#
回到最初的問題，分享是為了什麼呢？
我想起自己一開始辦這個分享，不是為了表現，而是為了解決溝通的痛點。那如果我現在壓力變大，要解決的問題也變得不明不白，那我應該做的不是撐下去，而是重新找回這場分享的意義所在。
我想，也許我不需要知道答案，我只需要會問對問題。
所以我做了一份問卷來搜集對於分享會的感想跟未來的期待聽到的題目。
噹噹，分數出爐，激勵了我不少，應該可以讓我小小在這裡的炫耀一下下吧（？
- 對主題的興趣：8.1/10
- 對我表達方式的評價：9.6/10
- 願意推薦這場分享：10/10
但比起分數，更重要的是我能知道這個方式是對的，那接下來就缺主題了。
我從問卷裡蒐集到的題目中挑出一部分，辦了一場小型的主題討論會。
我先提出對這些題目的想法，讓大家分享他們真正想知道關於題目的細節是什麼，接著再請大家投票決定主題受歡迎的程度。而我負責把這些題目拆成一場一場的分享。
簡單說，我還是主講人，但方向來自我的聽眾們。
三個學習轉折#
而在這兩年的知識分享，我學到的是很多：
-
不是想講什麼，而是能夠給什麼
有些原本覺得自己懂的東西，只有在開始講給別人聽時，才會發現自己其實沒有想清楚。這個分享會幫我補上了那些原本忽略的重要細節，讓我把會做的事變成能說清楚的知識。 -
學到得比任何人都更多
為了讓自己講得好，就需要拆解不同的設計，閱讀更多實作來提供範例，也需要重構自己表述的邏輯鏈。同時分享也變成一個我的學習循環，把我卡住的問題，變成下一週的主題。 -
在有限時間內，有效率地準備內容
後來持續一年中，我試著給自己進一步的限制來挑戰自己，例如 50 分鐘的分享會最多只有 90 分鐘的時間準備。這讓我練習在有限時間內邏輯化資訊的能力，不只對分享有幫助，對我做技術設計與提案也很有幫助。
除了分享這件事情本身讓我所學很多外，其實這兩年，我一直在想我真的還想繼續當軟體工程師嗎？我有時候也會懷疑自己是不是該做點別的事。
但神奇的是，這場分享會辦著辦著，我發現我還有很多想分享的事，也還是會對系統設計、團隊溝通、技術選型這些東西感到興奮，還想要知道為什麼這樣比較好，也還想繼續把這些經驗分享出去。而這些想知道和想說出來的衝動，應該就是答案了吧。
最後的最後，我想分享知識這件事，不一定非得是公開演講、也不一定非得做成文章、影片、或教材。有時候，它只是為了解決講到第三次已經不想再講第四次的狀況，然後可能不小心就發現設計出一個場域，讓大家一起走在這裡相互學習交流。
在這個過程找到了自己，也在過程中知道我想要成為的 Staff Engineer，可是有點理想的資深逐夢者。